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FOREWORD 


One  of  the  objectives  of  the  Air  Force  Center  for  Systems  Engineering  (AFCSE)  is  to 
develop  case  studies  focusing  on  the  application  of  systems  engineering  principles  within  various 
aerospace  programs.  The  intent  of  these  case  studies  is  to  examine  a  broad  spectrum  of  program 
types  and  a  variety  of  learning  principles  using  the  Friedman-Sage  Framework  to  guide  overall 
analysis.  In  addition  to  this  case,  the  following  studies  are  available  at  the  AFCSE  website. 

■  Global  Positioning  System  (space  system) 

■  Hubble  Telescope  (space  system) 

■  Theater  Battle  Management  Core  System  (complex  software  development) 

■  F-111  Fighter  (joint  program  with  significant  involvement  by  the  Office  of  the 
Secretary  of  Defense) 

■  C-5  Cargo  Airlifter  (very  large,  complex  aircraft) 

■  A- 1 0  Warthog  (ground  attack) 

■  Global  Hawk 

■  KC-135  Simulator 


These  cases  support  practitioners  of  systems  engineering  and  are  also  used  in  the 
academic  instruction  in  systems  engineering  within  military  service  academies  and  at  both 
civilian  and  military  graduate  schools.  Each  of  the  case  studies  comprises  elements  of  success  as 
well  as  examples  of  systems  engineering  decisions  that,  in  hindsight,  were  not  optimal.  Both 
types  of  examples  are  useful  for  learning.  Plans  exist  for  future  case  studies  focusing  on  various 
space  systems,  additional  aircraft  programs,  munitions  programs,  joint  service  programs, 
logistics-led  programs,  science  and  technology/laboratory  efforts,  and  a  variety  of  commercial 
systems. 

The  Department  of  Defense  (DOD)  continues  to  develop  and  acquire  joint  complex 
systems  that  deliver  needed  capabilities  to  our  war  fighters.  Systems  engineering  is  the  technical 
and  technical  management  process  that  focuses  explicitly  on  delivering  and  sustaining  robust, 
high-quality,  affordable  products.  The  Air  Force  leadership  has  collectively  stated  the  need  to 
mature  a  sound  systems  engineering  process  throughout  the  Air  Force. 

As  we  uncovered  historical  facts  and  conducted  key  interviews  with  program  managers 
and  chief  engineers,  both  within  the  government  and  those  working  for  the  various  prime  and 
subcontractors,  we  concluded  that  today’s  systems  programs  face  similar  challenges.  Applicable 
systems  engineering  principles  and  the  effects  of  communication  and  the  environment  continue 
to  challenge  our  ability  to  provide  a  balanced  technical  solution.  We  look  forward  to  your 
comments  on  this  case  study  and  the  others  that  follow. 

John  Paschall,  Col,  USAF 

Deputy  Director,  Air  Force  Center  for  Systems  Engineering 
Air  Force  Institute  of  Technology 
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EXECUTIVE  SUMMARY 


The  International  Council  on  Systems  Engineering  (INCOSE)  defines  Systems 
Engineering  (SE)  as  an  “interdisciplinary  approach  and  means  to  enable  the  realization  of 
successful  systems.  It  focuses  on  defining  customer  needs  and  required  functionality  early  in  the 
development  cycle,  documenting  requirements,  and  then  proceeding  with  design  synthesis  and 
system  validation  while  considering  the  complete  problem:  operations,  performance,  test, 
manufacturing,  cost  and  schedule,  training  and  support,  and  disposal.”'  This  case  study  on  the 
International  Space  Station  considers  what  many  believe  to  have  been  the  ultimate  international 
engineering  project  in  history.  The  initial  plans  involved  the  direct  participation  of  16  nations, 
88  launches  and  over  160  spacewalks — more  space  activities  than  NASA  had  accomplished  prior 
to  the  1993  International  Space  Station  decision. 

Probably  more  important  was  the 
significant  leap  in  System  Engineering 
(SE)  execution  that  would  be  required  to 
build  and  operate  a  multi-national  space 
station.  In  a  short  period  of  time,  NASA 
and  its  partners  had  to  work  out  how  to 
integrate  culturally  different  SE 
approaches,  designs,  languages  and 
operational  perspectives  on  risk  and 
safety. 

The  International  Space  Station 
(ISS)  traces  its  heritage  back  to  early  plans 
for  the  United  States  Maimed  Orbiting 
Eaboratory  (MOE)  program  to  the  US 
Skylab,  the  Shuttle’s  Space  Lab  and  then  through  the  multiple  Soviet  space  stations  culminating 
in  the  Mir.  With  the  successful  development  and  launch  of  the  Space  Shuttle,  the  United  States 
was  ready  to  take  on  a  much  larger  space  station  concept.  In  the  fall  of  1985,  NASA  put 
together  a  plan  for  a  dual-keel  design  with  multiple  US,  European  and  Japanese  research 
modules  along  with  Canada’s  planned  Mobile  Servicing  System.  By  1986,  this  had  changed 
due  to  the  Challenger  accident  and  other  safety  considerations.  A  major  new  addition  was  a 
new  “lifeboat”  vehicle  that  would  accommodate  emergency  returns  to  Earth.  All  of  these 
changes  caused  the  estimated  price  to  double.  By  the  end  of  the  1980s,  the  station  design  (now 
called  Space  Station  Ereedom)  had  shrunk  along  with  total  crew  (down  to  four),  electrical  power 
generation  (from  75  to  56  kw)  and  for  budgetary  reasons,  there  was  no  defined  end-state  for  the 
station.  By  1990,  the  modified  station  cost  was  several  times  higher  than  the  original  plan.^ 

By  1993,  the  station  design  had  continued  to  evolve  and  cost  estimates  continued  to 
grow.  The  new  Clinton  administration  set  up  a  blue  ribbon  panel  to  look  at  the  space  station  and 


'  INCOSE  website:  http://www.incose.org/practice/whatissystemseng.aspx 

^  “Systems  Engineering  Challenges  of  the  International  Space  Station,”  Mark.  D.  Jenks,  2000  NAE  Symposium  on 
Frontiers  in  Engineering. 

^  “Nasa’s  Space  Station  Program:  Evolution  of  its  Rationale  and  Expected  Uses,”  Marcia  S.  Smith,  Congressional 
Research  Service,  Testimony  before  the  Subcommittee  on  Science  and  Space,  United  States  Senate,  April  20,  2005. 
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determine  a  new  design  that  would  fit  within  available  budget.  The  new  design,  eventually 
ealled  the  International  Spaee  Station  (ISS),  would  still  be  an  international  effort  but  would  now 
inelude  the  addition  of  Russia  as  a  major  eontributor  of  ISS  modules  and  support.  As  the 
program  progressed  and  assembly  began,  eosts  grew  along  with  sehedule  delays.  By  2002, 
NASA  was  looking  for  a  way  to  signifieantly  reduee  eosts  and  to  eomplete  the  station.  This 
involved  the  eaneellation  of  a  few  modules  along  with  the  emergeney  erew  return  vehiele.  The 
original  plan  ealled  for  6-7  astronauts  full  time  doing  researeh  and  this  was  eonsidered  for  a 
reduetion  to  3."^  Estimated  eost  for  eompletion  inereased  and  the  sehedule  slipped  with  a  new 
eompletion  date  of  2004. 

By  2004,  in  the  aftermath  of  the  Columbia  aeeident,  the  sehedule  and  budget  had  grown 
and  ISS  eompletion  was  now  seheduled  for  2010.  President  Bush  announeed  a  new  NASA 
Vision  for  Spaee  Exploration  whieh  plaeed  less  emphasis  on  the  ISS  and  started  development  of 
a  new  fleet  of  vehieles  that  someday  would  go  to  the  Moon,  Mars  and  beyond.  To  make  the 
budget  available  for  this  new  effort,  the  Shuttle  would  be  retired  in  2010  with  the  eompletion  of 
the  ISS  assembly.  The  ISS  retirement  date  was  unelear,  possibly  as  early  as  2016.  These 
deeisions  do  provide  an  end  state  for  ISS  eonstruetion,  but  raise  risk  issues  about  US  aceess  to 
the  station  after  Shuttle  retirement  and  before  the  next  generation  of  US  manned  orbital  vehieles 
will  be  ready. 

Not  to  downplay  the  major  eost  and  sehedule  issues,  the  systems  engineering  challenge 
on  the  ISS  was  equally  monumental.  NASA  had  to  quickly  learn  how  to  adapt  its  SE 
approaches  to  include  an  awareness  of  those  of  the  international  partnership.  NASA  has  its  own 
challenges  of  multiple  centers  with  their  own  SE  differences  and  approaches.  NASA  had  to 
learn  how  to  operate  as  a  “managing  partner”  to  accommodate  its  International  Partners  (IPs). 
A  major  effort  was  involved  in  developing  the  partnership  agreements,  allocating  costs  and  usage 
rights,  and  determining  operational  control.  Under  the  new  ISS  partnership,^  NASA  was  the 
first  IP  among  equals,  with  each  board  chaired  by  the  NASA  representative.  In  cases  where 
consensus  could  not  be  reached,  the  NASA  representative  technically  had  the  right  to  make  a 
decision  for  the  board;  however,  this  right  was  rarely  used  in  practice. 

NASA  was  concerned  about  maintaining  schedule  and  cost  on  the  ISS  program,  because 
failures  would  not  be  tolerated  by  Congress.  Initial  program  strategy  was  for  no  IP  to  be  on  the 
critical  path,  which  would  allow  NASA  more  control  to  reduce  risk.  As  it  turned  out,  however, 
the  Russians  ended  up  providing  the  first  two  major  modules  that  were  at  the  front  of  the  critical 
path. 


NASA  had  to  solve  many  major  SE  challenges.  It  had  to  figure  out  how  to  coordinate 
and  integrate  all  of  the  IPs  and  their  highly  integrated  modules: 


“Nasa’s  Space  Station  Program:  Evolution  of  its  Rationale  and  Expected  Uses,”  Marcia  S.  Smith,  Congressional 
Research  Service,  Testimony  before  the  Subcommittee  on  Science  and  Space,  United  States  Senate,  April  20,  2005. 

^  “Lessons  Learned  and  Recommendations  on  International  Participation  from  the  International  Space  Station 
Program,”  Daniel  V.  Jacobs  and  Michael  J.  See,  Lyndon  B.  Johnson  Space  Center,  Sept.  2004. 
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■  The  integration  ehallenge  was  further  hindered  by  a  laek  of  eomputer  and  information 
teehnology  capability  both  at  NASA  and  its  partners  (especially  the  Russians).  The  ISS 
helped  accelerate  NASA’s  upgrade  of  its  information  technology  systems  and  adoption  of 
a  full  email  and  web  focused  data  exchange  system.  Within  the  constraints  of  federal  law, 
NASA  had  to  supply  computers  and  software  to  the  Russians. 

■  The  Russians  had  a  very  different  approach  to  SE,  risk,  and  safety.  The  Russians  had 
significant  on-orbit  experience  with  the  MIR  and  its  predecessors,  which  drove  their  SE 
approaches.  Eor  instance,  they  tended  to  be  more  conservative  and  evolutionary  in 
design.  A  prime  example  is  their  Soyuz/Progress  vehicle  designs,  which  are  directly 
traceable  to  their  1960s  designs.  They  also  utilized  an  approach  that  could  best  be 
described  as  “dissimilar  redundancy”.  In  this  mode  different  systems  can  be  utilized  to 
provide  a  basic  capability. 

■  The  ISS  design,  development  and  construction  began  with  Space  Station  Ereedom  design 
work  in  the  1980s  and  are  not  scheduled  to  conclude  until  2010,  with  operations 
continuing  until  2016  and  possibly  beyond,  requiring  NASA  to  solve  major  obsolescence, 
logistics,  and  technology  issues.  The  length  of  the  program  has  created  major  personnel 
challenges  as  NASA  attempts  to  capture,  manage,  and  create  program  knowledge  while 
dealing  with  significant  career  progression  issues  of  its  personnel. 

■  The  on-orbit  assembly  of  the  ISS  created  a  major  operational  configuration  challenge. 
Each  on-orbit  configuration  had  to  operate  as  a  stand-alone  space  station,  requiring 
multiple  design  baselines  for  the  structure,  hardware,  and  operational  systems.  NASA 
basically  developed  a  new  version  of  spiral  construction  theory. 

■  NASA  and  its  IPs  had  to  develop  innovative  methods  to  test  and  verify  interfaces.  One  of 
the  most  significant  of  these  involved  Multi-Element  Integrated  Testing  solutions  for  the 
station  components  and  then  creating  a  complex  test  plan  and  hardware/software  solution 
for  each  configuration. 

■  NASA  had  to  develop  expertise  in  supporting  its  systems  engineering  approach  while 
adjusting  to  the  realities  of  a  complex  external  environment  including  international 
politics  across  many  partner  nations.  At  times,  optimal  technical  solutions  conflicted 
with  political  constraints,  and  prohibitions  created  by  the  Iran,  North  Korea  and  Syria 
Non-Proliferation  Act,  and  International  Traffic  in  Arms  Regulations  (ITAR). 

Part  of  this  problem  was  solved  by  adopting  an  integrated  product  team  (IPT)  approach.  This 

approach  was  utilized  in  a  broad  manner  after  the  1993  redesign  activity.  Its  use  diminished  as 

the  design  and  development  phase  came  to  completion. 


VI 


THIS  PAGE  INTENTIONALLY  BLANK 


TABLE  OF  CONTENTS 


Foreword . i 

Acknowledgments. . ii 

Executive  Summary . iv 

Table  of  Contents . viii 

List  of  Figures . xi 

List  of  Tables . xiii 

1. 0  SYSTEMS  ENGINEERING  PRINCIPLES . I 

1.1  General  Systems  Engineering  Process . 1 

1.1.1  Introduction . 1 

1.1.2  Case  Studies . 3 

1.1.3  Framework  for  Analysis . 4 

1.2  ISS  Major  Learning  Principles  and  Friedman-Sage  Matrix . 6 

2.0  INTERNATIONAL  SPACE  STATION  PROGRAM  JOURNEY . 7 

2.1  Historical  Background . 7 

2.1.1  Soviet  Space  Stations . 8 

2.1.2  Skylab . 9 

2. 1 .3  Space  Station  Freedom . 9 

2.1.4  Shuttle-Mir  Program . 9 

2.2  Space  Station  Freedom  Redesign . 12 

2.2.1  Budget . 12 

2.2.2  Studies/Review  Panels . 13 

2.2.3  Changes  from  SSF  to  ISS . 14 

2.3  NASA  Systems  Engineering  Environment . 16 

2.3.1  NASA  Management  Approaeh . 16 

2.3.2  NASA  Center  Approaches . 20 

2.3.3  System  Engineers  and  the  Experience  Chain . 20 

2.3.4  Systems  Engineering  Challenges  of  the  ISS . 22 

2.3.5  Systems  Engineering  Process . 23 

2.3.6  International  Partners . 24 

2.3.7  Safety/Risk  approaches . 27 

3.0  FULL  SCALE  DEVELOPMENT. . 32 

3.1  Major  ISS  Modules . 32 

viii 


3.1.1  Zarya  Control  Module . 32 

3.1.2  Unity  Node . 33 

3.1.3  Zvezda  Service  Module . 33 

3.1.4  Destiny  Laboratory  Module . 34 

3.1.5  Canadian  Space  Robotics  System . 36 

3.1.6  Quest  Joint  Airlock . 36 

3.1.7  Russian  Pirs  Docking  Compartment . 38 

3.1.8  Columbus  Laboratory . 39 

3.1.9  Kibo  Japanese  Experimental  Laboratory . 40 

3.1.10  Cupola . 43 

3.1.11  Russian  Multi-Purpose  Laboratory  Module . 43 

3.1.12  Multi-Purpose  Logistics  Module . 45 

3.2  Launch  Services . 46 

3.2.1  Shuttle . 46 

3.2.2  New  NASA  capability . 47 

3.2.3  Russian  Vehicles . 47 

3.2.4  Japanese  Projects . 49 

3.2.5  European  Projects . 49 

3.2.6  Commercial  Capabilities . 49 

3.3  Development  Challenges . 50 

3.3.1  Technology  Readiness  and  Obsolescence . 51 

3.3.2  Use  of  Probabilistic  Risk  Assessment . 52 

3.3.3  Russian  Contribution  and  Risk . 53 

3.3.4  Spiral  Construction  Approach  and  Multi-configuration  issues . 54 

3.3.5  Computer  Hardware  and  Software . 54 

3.3.6  Power  Systems . 58 

3.3.7  Micrometeoroid  and  Orbital  Debris  (MMOD)  Protection . 60 

3.3.8  Test  and  Integration . 61 

3.4  Execution  Issues . 66 

3.4.1  Unrealistic  Estimates  for  Cost  and  Schedule . 66 

3.4.2  Iran,  North  Korea,  and  Syria  Nonproliferation  Act . 68 

3.4.3  IS S  Eogistical  Support . 69 

3.4.4  Handling  a  Major  Computer  Eailure . 70 

3.4.5  Transportation . 73 

3.4.6  Anomaly  Resolution  and  the  Columbia  Accident . 80 

3.4.7  Major  Risks  to  the  IS S . 81 

3.5  Long  Term  Outlook . 84 

4.0  SUMMARY. . 86 

4,1  Summary . 86 

ix 


4,2  Lessons  Learned 


87 


APPENDICES . 89 

APPENDIX  1.  AUTHOR  BIOGRAPHIES . 90 


Among  his  numerous  awards,  he  is  a  recipient  of  NASA’s  Exceptional  Achievement 
Medal,  the  Director’s  Special  Commendation,  and  the  coveted  Silver  Snoopy  award- 
the  only  award  to  fly  in  space.  He  routinely  advises  numerous  academic  programs  and 


institutions,  and  he  is  a  champion  of  education  throughout  the  world . 91 

APPENDIX  2.  ACRONYMS . 92 

APPENDIX  3.  SPACELAB  MISSIONS . 96 

APPENDIX  4,  PHASE  ONE— SHUTTLE-MIR  MISSIONS . 97 


APPENDIX  5.  INTERNATIONAL  SPACE  STATION  MISSION  SUMMARIES . 99 


X 


LIST  OF  FIGURES _ 

Figure  1 .  The  Systems  Engineering  Process  as  presented  by  the  Defense  Acquisition  University . 2 

Figure  2.  US  Manned  Orbiting  Laboratory  (USAF  Image) . 7 

Figure  3.  Soviet  ALMAZ  Space  Station . 8 

Figure  4.  Soviet  Salyut  6  Space  Station . 8 

Figures.  US  Skylab  Space  Station . 9 

Figure  6.  US  Shuttle  Docked  with  the  Russian  MIR  Space  Station . 10 

Figure  7.  Damage  to  the  Soviet  MIR  from  Docking  Accident . 12 

Figure  8.  NASA  and  International  Partner  Operations  Scope . 16 

Figure  9.  Systems  Engineering  Integration  Boards . 19 

Figure  10.  Russian  Zarya  Module . 32 

Figure  11.  US  Unity  Module . 33 

Figure  12.  Zvezda  Module  with . 34 

Figure  13.  US  Destiny  Laboratory  Module . 35 

Figure  14.  US  Destiny  Module  High  Grade  Optical  Window . 35 

Figure  15.  Canadian  Space  Robotics  System . 36 

Figure  16.  US  Quest  Airlock . 38 

Figure  17.  Russian  Pirs  Docking  Compartment . 38 

Figure  18.  ESA  Columbus  Research  Module . 40 

Figure  19.  Japanese  Kibo  Experimental  Module  and  Facilities . 42 

Figure  20.  Cupola  Observation  Modules . 43 

Figure  2 1 .  Russian  Multi-Purpose  Laboratory  Module . 44 

Figure  22.  Interior  of  Italian  Multi-Purpose  Logistics  Modules . 45 

Figure  23.  US  Shuttle  Docked  with  the  ISS . 46 

Figure  24.  Russian  Soyuz  Manned  Vehicle . 48 

Figure  25.  Russian  Progress  Unmanned  Cargo  Vehicle . 48 

Figure  26.  Japanese  Unmanned  H-11  Transfer  Vehicle . 49 

Figure  27.  European  Unmanned  Automated  Transfer  Vehicle . 49 

Figure  28.  US  SpaceX  Unmanned  Cargo  Vehicle . 50 

Figure  29.  Orbital  Sciences  Cygnus  Unmanned  Cargo  Vehicle . 50 

Figure  30.  Single  Channel  Power  Flow  Diagram . 59 

xi 


Figure  3 1 .  Average  Micrometeoroid  Environment  for  IS  S . 60 

Figure  32.  Multi  Element  Integrated  Test  Configurations  for  the  ISS . 64 

Figure  33.  Multi  Element  Integrated  Test  2  Set  Up  for  the  ISS . 65 

Figure  34.  NASA  Cost  and  Schedule  Overruns . 66 

Figure  35.  NASA  Schedule  Outcomes . 67 

Figure  36.  STS-1 17  Extra- Vehicular  Activity  at  ISS . 71 

Figure  37.  Stowed  Solar  Panel  Being  Unfolded  for  Deployment . 71 

Figure  38.  Space  Shuttle . 74 

Figure  39.  Soyuz  Manned  Vehicle . 76 

Figure  40.  Fire  at  Scene  of  Soyuz  Capsule  Landing . 77 

Figure  41.  Space  Exploration  Falcon  1  Rocket . 78 

Figure  42.  Orion  Visiting  the  ISS . 86 


xii 


LIST  OF  TABLES 


Table  1.  Framework  of  Key  Systems  Engineering  Concepts  and  Responsibilities . 5 

Table  2.  Technology  Readiness  Levels . 5 1 

Table  3.  Probability  of  Penetration  Damage  to  the  ISS . 81 


xiii 


THIS  PAGE  INTENTIONALLY  BLANK 


XIV 


1.0  SYSTEMS  ENGINEERING  PRINCIPEES 


1.1  General  Systems  Engineering  Process 

1.1.1  Introduction 

The  Elnited  States  government  eontinues  to  develop  and  aequire  new  systems  and  to  meet 
the  seientifie  needs  of  our  growing  nation.  With  a  eonstant  objeetive  to  improve  and  mature  the 
aequisition  proeess,  the  Elnited  States  eontinues  to  pursue  new  and  ereative  methodologies  to 
purehase  these  teehnieally  eomplex  systems.  A  sound  systems  engineering  proeess  (hereafter 
referred  to  as  the  SE  proeess),  foeused  explieitly  on  delivering  and  sustaining  robust,  high- 
quality,  affordable  produets  that  meet  the  needs  of  eustomers  and  stake  holders,  must  eontinue  to 
evolve  and  mature.  Systems  engineering  eneompasses  the  teehnieal  management  proeess  that 
results  in  delivered  produets  and  systems  that  exhibit  the  best  balanee  of  eost  and  performanee 
with  the  highest  resultant  teehnieal  integrity.  The  SE  proeess  must  operate  effeetively  with 
desired  mission-level  eapabilities,  establish  system-level  requirements,  alloeate  these  down  to  the 
lowest  level  of  the  design,  and  ensure  validation  and  verifieation  of  performanee,  meeting  eost 
and  sehedule  eonstraints.  The  systems  engineering  proeess  evolves  as  the  program  progresses 
from  one  phase  to  the  next,  as  do  the  tools  and  proeedures.  The  proeess  also  ehanges  over  the 
deeades,  maturing,  expanding,  growing,  and  evolving  from  the  base  established  during  the 
eonduet  of  past  programs.  Examples  ean  be  found  demonstrating  a  systemie  applieation  of 
effeetive  engineering  and  engineering  management,  as  well  as  poorly  applied,  but  well-defined 
proeesses.  Throughout  the  many  deeades  during  whieh  systems  engineering  has  emerged  as  a 
diseipline,  many  praetiees,  proeesses,  heuristies,  and  tools  have  been  developed,  doeumented, 
and  applied. 

Several  eore  lifeeyele  stages  have  surfaeed  as  eonsistently  and  eontinually  ehallenging 
during  any  system  program  development.  Eirst,  system  development  must  proeeed  from  a  well- 
developed  set  of  requirements.  Seeondly,  regardless  of  the  evolutionary  aequisition  approaeh, 
the  system  requirements  must  flow  down  to  all  subsystems  and  lower  level  eomponents.  And 
third,  the  system  requirements  need  to  be  stable,  balaneed  and  must  properly  refleet  all  aetivities 
in  all  intended  environments.  However,  system  requirements  are  not  unehangeable.  As  the 
system  design  proeeeds,  if  a  requirement  or  set  of  requirements  is  proving  exeessively  expensive 
to  satisfy  or  beeomes  otherwise  unsupportable,  the  proeess  must  rebalanee  sehedule,  eost,  and 
performanee  by  ehanging  or  modifying  the  requirements  or  set  of  requirements  with  eustomer 
eoneurrenee. 

Systems  engineering  ineludes  making  key  system  and  design  trades  early  in  the  proeess  to 
establish  the  system  arehiteeture.  These  arehiteetural  artifaets  ean  depiet  any  new  system,  legaey 
system,  modifieations  thereto,  introduetion  of  new  teehnologies,  and  overall  system-level 
behavior  and  performanee.  Modeling  and  simulation  are  generally  employed  to  organize  and 
assess  arehiteetural  alternatives  at  this  introduetory  stage.  System  and  subsystem  design  follows 
the  funetional  arehiteeture.  System  arehiteetures  are  modified  if  the  elements  are  too  risky, 
expensive,  or  time-eonsuming.  Both  newer  objeet-oriented  analysis  and  design  and  elassie 
struetured  analysis  using  funetional  deeomposition  and  information  fiows/data  modeling  oeeur. 
Design  proeeeds  logieally  using  key  design  reviews,  tradeoff  analysis,  and  prototyping  to  reduee 
any  high-risk  teehnology  areas. 
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Important  to  the  efficient  decomposition  and  creation  of  the  functional  and  physical 
architectural  designs  are  the  management  of  interfaces  and  integration  of  subsystems.  This  is 
applied  to  subsystems  within  a  system,  or  across  large,  complex  systems  of  systems,  and  requires 
acknowledgement  of  the  human  as  an  integral  element  of  the  system.  Once  a  solution  is  planned, 
analyzed,  designed,  and  constructed,  validation  and  verification  take  place  to  ensure  satisfaction 
of  requirements.  Definitions  of  test  criteria,  measures  of  effectiveness  (MOEs),  and  measures  of 
performance  (MOPs),  established  as  part  of  the  requirements  process,  take  place  well  before  any 
component/subsystem  assembly  design  and  construction  occurs. 

Several  excellent  representations  of  the  systems  engineering  process  are  presented  in  the 
literature.  These  depictions  present  the  current  state  of  the  art  in  the  maturity  and  evolution  of 
the  systems  engineering  process.  One  can  find  systems  engineering  process  definitions,  guides, 
and  handbooks  from  the  National  Aeronautics  and  Space  Administration,  International  Council 
on  Systems  Engineering  (INCOSE),  Electronics  Industrial  Association  (EIA),  Institute  of 
Electrical  and  Electronics  Engineers  (IEEE),  International  Standards  Organization  (ISO),  and 
various  Department  of  Defense  (DoD)  agencies  and  organizations.  They  show  the  process  as  it 
should  be  applied  by  today’s  experienced  practitioner.  One  of  these  processes,  long  used  by  the 
Defense  Acquisition  University  (DAU),  is  depicted  in  Eigure  1.  It  should  be  noted  that  this 
model  is  not  accomplished  in  a  single  pass.  This  iterative  and  nested  process  gets  repeated  to  the 
lowest  level  of  definition  of  the  design  and  its  interfaces. 


Process  Input 

•  CusIcmerNeed&'Objectives' 
Requirements 

-  Missbns 

-  Measures  of  Effectiveness 
-Environments 
-Constraints 

•  Technology  Base 

•  Output  Requirements  from  FVior 
OevelcfzmenI  Efbrt 

•  n'ogtam  Decision  Requirements 

•  Requirements  Apfiiied  Through 
Spedficatbns  and  Standards 


Related  Terms: 

Customer  =  Organizatbns  responsible  fcr  Primary  Functbns 
Primary  Fundbns  =  Development.  ^oduction'ConsIructbn.  Verification. 

Oepfoyment.  Operations.  Support.  Training.  Disposal 
Systems  Elements  -  Hardware.  Software.  Personnel.  Facilities.  Data.  Material 
Services.  Techniques 


Process  Output 
>  Develc^ent  Level  Dependent 

-  Decision  Database 

-  Systerrs'Configuration  Item 
Architecture 

-Specrficationeand  Baselines 


Figure  1.  The  Systems  Engineering  Process  as  presented  by  the 
Defense  Acquisition  University 
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The  DAU  model,  like  all  others,  has  been  doeumented  in  the  last  two  deeades  and  has 
expanded  and  developed  to  reflect  a  changing  environment.  Systems  are  becoming  increasingly 
complex  internally  and  more  interconnected  externally.  The  process  used  to  develop  aircraft  and 
other  weapons  of  the  past  was  a  process  effective  at  that  time.  It  served  the  needs  of  the 
practitioners  and  resulted  in  many  successful  systems  in  our  inventory.  However,  the  cost  and 
schedule  performance  records  of  the  past  programs  are  fraught  with  examples  of  some  well- 
managed  programs  and  programs  with  less  than  perfect  execution.  As  the  nation  entered  the 
1980s  and  1990s,  large  DoD  and  commercial  acquisitions  were  overrunning  costs  and  running 
behind  schedule.  The  aerospace  industry  and  its  organizations  were  becoming  larger  and  more 
geographically  and  culturally  distributed.  As  applied  within  the  conflnes  of  a  single  system  or  a 
single  company  the  early  systems  engineering  process,  was  no  longer  the  norm. 

Today,  many  factors  overshadow  new  acquisitions,  including  System-of-Systems  (SoS) 
context,  network  centric  warfare  and  operations,  and  the  rapid  growth  in  information  technology. 
These  factors  have  driven  a  new  form  of  emergent  systems  engineering,  which  focuses  on  certain 
aspects  of  the  traditional  process.  One  of  these  increased  areas  of  focus  resides  in  the 
architectural  definitions  used  during  system  analysis.  This  process  is  differentiated  by  greater 
reliance  on  reusable  architectural  views  describing  the  system  context  and  concept  of  operations, 
interoperability,  information  and  data  flows  and  network  service-oriented  characteristics. 

1.1.2  Case  Studies 

The  systems  engineering  process  to  be  used  in  today’s  complex  SoS  projects  is  a  process 
matured  and  founded  on  the  principles  of  systems  developed  in  the  past.  The  examples  of 
systems  engineering  used  in  other  programs,  both  past  and  present,  provide  many  lessons  to  be 
used  in  applying  and  understanding  today’s  process. 

The  purpose  of  developing  detailed  case  studies  is  to  support  the  teaching  of  systems 
engineering  principles.  The  systems  engineering  case  studies  assist  in  discussion  of  both 
successful  and  unsuccessful  methodologies,  processes,  principles,  tools,  and  decision  material  to 
assess  the  outcome  of  alternatives  at  the  program/system  level.  In  addition,  the  importance  of 
using  skills  from  multiple  professions  and  engineering  disciplines  and  collecting,  assessing,  and 
integrating  varied  functional  data  is  emphasized.  Analysis  of  these  aspects  will  provide  the 
student  with  real-world,  detailed  examples  of  how  the  process  plays  a  significant  role  in 
balancing  cost,  schedule,  and  performance. 

The  utilization  and  mis-utilization  of  systems  engineering  principles  are  highlighted,  with 
special  emphasis  on  the  conditions  that  foster  or  impede  good  systems  engineering  practices. 
Case  studies  should  be  used  to  illustrate  both  good  and  bad  examples  of  acquisition  management 
and  learning  principles,  to  include  determining  whether: 

■  Every  system  provides  a  balanced  and  optimized  product  to  a  customer. 

■  Effective  requirements  analysis  was  applied. 

■  Consistent  and  rigorous  application  of  systems  engineering  management  standards 
was  applied. 

■  Effective  test  planning  was  accomplished. 

■  Effective  major  technical  program  reviews  were  conducted. 
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■  Continuous  risk  assessments  and  management  adjustments  were  implemented. 

■  Reliable  cost  estimates  and  policies  were  developed. 

■  Disciplined  application  of  configuration  management  was  demonstrated. 

■  A  well-defined  system  boundary  was  defined. 

■  Disciplined  methodologies  were  developed  for  complex  systems. 

■  Problem  solving  methods  incorporated  understanding  of  the  system  within  the  larger 
environment  (customer’s  customer). 

The  systems  engineering  process  transforms  an  operational  need  into  a  set  of  system 
elements.  These  system  elements  are  allocated  and  translated  by  the  systems  engineering 
process  into  detailed  requirements.  The  systems  engineering  process,  from  the  identification  of 
the  need  to  the  development  and  utilization  of  the  product,  must  continuously  integrate  and 
optimize  system  and  subsystem  performance  within  cost  and  schedule  to  provide  an 
operationally  effective  system  throughout  its  life  cycle.  Case  studies  highlight  the  various 
interfaces  and  communications  to  achieve  this  optimization,  which  include: 

■  The  program  manager/sys terns  engineering  interface,  which  is  essential  between  the 
operational  user  and  developer  (acquirer)  to  translate  the  needs  into  the  performance 
requirements  for  the  system  and  subsystems. 

■  The  govemment/contractor  interface,  essential  for  the  practice  of  systems  engineering 
to  translate  and  allocate  the  performance  requirements  into  detailed  requirements. 

■  The  developer  (acquirer)/user  interface  within  the  project,  essential  for  the  systems 
engineering  practice  of  integration  and  balance. 

The  systems  engineering  process  must  manage  risk,  known  and  unknown,  as  well  as 
internal  and  external.  This  objective  specifically  focuses  on  external  factors  and  the  impact  of 
uncontrollable  influences,  such  as  actions  of  Congress,  changes  in  funding,  new 
instructions/policies,  changing  stakeholders  or  user  requirements  or  contractor  and  government 
staffing  levels. 

Lastly,  the  systems  engineering  process  must  respond  to  “Mega-Trends”  in  the  systems 
engineering  discipline  itself,  as  the  nature  of  systems  engineering  and  related  practices  vary  with 
time. 

1.1,3  Framework  for  Analysis 

This  case  study  is  presented  in  a  format  that  follows  the  learning  principles  specifically 
derived  for  the  International  Space  Station,  utilizing  the  Friedman- S age °  framework  to  organize 
the  assessment  of  the  application  of  the  systems  engineering  process.  The  framework  and  the 
derived  matrix  can  play  an  important  role  in  developing  case  studies  in  systems  engineering  and 
systems  management,  especially  case  studies  that  involve  systems  acquisition.  The  framework 
presents  a  nine  row  by  three  column  matrix  shown  in  Table  1. 


Case  Studies  of  Systems  Engineering  and  Management  in  Systems  Acquisition,  George  Friedman  and  Andrew  Sage,  Systems 
Engineering,  Vol.  7,  No.  1,  2004,  ©  2003  Wiley  Periodicals,  Inc. 
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Table  1.  Framework  of  Key  Systems  Engineering  Concepts  and  Responsibilities 


Concept  Domain 

Responsibility  Domain 

1.  Contractor 
Responsibility 

2.  Shared 

Responsibility 

3.  Government 
Responsibility 

A.  Requirements  Definition  and  Management 

B.  Systems  Architecting  and  Conceptual  Design 

C.  System  and  Subsystem  Detailed  Design  and 
Implementation 

D.  Systems  and  Interface  Integration 

E.  Validation  and  Verification 

F.  Deployment  and  Post  Deployment 

G.  Life  Cycle  Support 

H.  Risk  Assessment  and  Management 

I.  System  and  Program  Management 

Six  of  the  nine  concept  domain  areas  in  Table  1  represent  phases  in  the  systems 
engineering  life  cycle: 

A.  Requirements  Definition  and  Management 

B.  Systems  Architecting  and  Conceptual  Design 

C.  System  and  Subsystem  Design  and  Implementation 

D.  Systems  and  Interface  Integration 

E.  Validation  and  Verification 

F.  Deployment  and  Post  Deployment 

Three  of  the  concept  areas  represent  necessary  process  and  systems  management  support: 

G.  Life  Cycle  Support 

H.  Risk  Assessment  and  Management 

I.  System  and  Program  Management 

While  other  concepts  could  have  been  identified,  the  Friedman-Sage  framework  suggests 
these  nine  are  the  most  relevant  to  systems  engineering  in  that  they  cover  the  essential  life  cycle 
processes  in  systems  acquisition  and  the  systems  management  support  in  the  conduct  of  the 
process.  Most  other  concept  areas  identified  during  the  development  of  the  matrix  appear  to  be 
subsets  of  one  of  these  areas.  The  three  columns  of  this  two-dimensional  framework  represent 
the  responsibilities  and  perspectives  of  government,  the  contractor,  and  the  shared 
responsibilities  between  the  government  and  the  contractor. 

The  Friedman-Sage  matrix  is  not  a  unique  systems  engineering  applications  tool,  but 
rather  a  disciplined  approach  to  evaluate  the  systems  engineering  process,  tools,  and  procedures 
as  applied  to  a  program.  The  Friedman-Sage  matrix  is  based  on  two  major  premises  as  the 
founding  objectives: 
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1 .  In  teaching  systems  engineering,  case  studies  can  be  instructive  in  that  they  relate 
aspects  of  the  real  world  to  the  student  to  provide  valuable  program  experience 
and  professional  practice  to  academic  theory. 

2.  In  teaching  systems  engineering,  there  has  previously  been  little  distinction 
between  duties  and  responsibilities  of  the  government  and  industry  activities. 
More  often  than  not,  the  government  role  in  systems  engineering  is  the  role  of  the 
requirements  developer. 

1,2  ISS  Major  Learning  Principles  and  Friedman-Sage  Matrix 

The  authors’  selection  of  learning  principles  from  the  Friedman-Sage  matrix  is  reflected  in 
the  Executive  Summary  of  this  case  study  (separate  attachment). 

The  systems  engineering  of  the  ISS  was  necessarily  biased  towards  government-led 
integration,  owing  to  the  numerous  intergovernmental  agreements  executed  between  the  US  and 
its  International  Space  Station  partners. 
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2.0  INTERNATIONAL  SPACE  STATION  PROGRAM 

JOURNEY 

2,1  Historical  Background 

Humans  have  always  looked  up  at  the  sky  and  imagined 
what  it  might  be  like  to  view  the  earth  from  outer  spaee  or  the 
heavens.  The  first  recorded  reference  to  a  space  station  as  we  know 
it  today  was  in  a  short  story^  by  Edward  Everett  Hale  entitled  “The 
Brick  Moon”  in  1869.  The  space  station  or  brick  moon  was  to  serve 
as  a  navigation  aid  to  sailors  much  as  the  stars  or  moon  did  for 
centuries.  Hale’s  space  station  was  not  practical,  because  it  was 
constructed  of  bricks,  had  no  propulsion  and  its  inhabitants  could 
actually  wave  at  the  ships  and  jump  up  and  down  to  make  the 
station  vibrate  as  a  warning  signal.  While  not  a  physicist,  he 
identified  an  early  concept  to  use  orbiting  satellites  to  aid  in 
navigation — a  very  crude  Global  Positioning  Satellite  (GPS). 

o 

Later,  in  1923  ,  Hermann  Oberth  wrote  of  space  travel  to  the  moon 
and  beyond  starting  from  an  orbiting  “space  station” — ^which  was 
the  first  coining  of  the  term.  He  even  published  the  first  concept  of 
a  wheel-like  space  station.^  In  1952,  Dr.  Werner  von  Braun  (a 


ManoBtl  Orbiting 
Laboratorfi  (MOLj 

Oemlnl 

CkpBiile 

n 

Adaptisr/  LbIi 
InterfBcs 

1 

1 

Lliriiu 

Hcidiile 

Lmtaantcizy  f 
ExparliCBiit 
Hbidiile 

former  student  of  Oberth)  published  an  important 

article  in  Colliers  magazine  about  his  idea  for  a  Figure  2.  US  Manned  Orbiting  Laboratory 
rotating  space  station  in  a  1000-mile  high  orbit.  In  (USAF  Image) 

1959,  the  U.S.  Army  began  a  study  called  Project 

Horizon* * ** ***’  to  consider  building  a  permanent  outpost  on  the  Moon  along  with  a  possible  space 
station.  The  Department  of  Defense  (DoD)  began  a  program  called  Manned  Orbiting 
Laboratory**  (MOL)  in  December  1963  (Eigure  2).  Its  purpose  was  to  provide  a  reconnaissance 
capability  to  the  Air  Eorce  and  establish  the  first  manned  military  space  program.  The  program 
was  eventually  cancelled  in  June  1969. 


’  “The  Brick  Moon,”,  Edward  Everett  Hale,  The  Atlantic  Monthly,  1869 

*  By  Rocket  to  Space.  Hermann  Oberth,  1923 

^  Frontiers  of  Space  Exploration,  Roger  D.  Lanins,  Greenwood  Press,  1998 

***  “Project  Horizon  Report:  A  US  Army  Study  for  the  Establishment  of  a  Permanent  Lunar  Outpost,”  9  June  1959. 
*’  “Best  Laid  Plans:  A  History  of  the  Manned  Orbiting  Laboratory,”  Steven  Strom,  Aerospace  Corporation. 


7 


Figure  3.  Soviet  ALMAZ  Space  Station 


2,1,1  Soviet  Space  Stations 

The  Soviet  Union  launched  the 
first  space  station  in  its  early  Almaz  and 
Soyuz  programs.  An  early  Almaz  design 
is  shown  in  Figure  3.  These  early  space 
stations  were  developed  and  built  in  the 
1964-1977  timeframe.  They  were 
relatively  small  and  could  not  be  refueled 
or  resupplied  (other  than  what  the 
arriving  crews  brought  in  their  small 
Soyuz  capsules).  These  stations  were 
placed  in  orbit  by  Proton  rockets  with  the 
crew  to  follow  in  Soyuz  capsules.  They 
were  marginally  successful  with  at  least 
five  built;  one  failed  to  achieve  orbit,  but 
at  least  four  were  occupied  by  one  or 
more  crews.  The  first  successful  mission 
occurred  in  1971.  However,  the 
successful  docking  was  overshadowed  by 
the  deaths  of  the  Soyuz- 11  crew  due  to  a 
failed  pressure  equalization  system  that 
asphyxiated  Georgi  Dobrovolski, 

Vladislav  Volkov,  and  Viktor  Patsayev 

The  second  generation  of  Soviet 
space  stations  flew  from  1977-1985. 

These  were  slightly  larger  but  had  the 
capability  to  be  refueled  and  resupplied 
by  automated  Progress  capsules — a  major  Figure  4.  Soviet  Salyut  6  Space  Station 

technological  achievement.  As  shown  in 

Figure  4,  the  Salyut  6  space  station  was  considerably  larger  than  previous  stations  and  allowed 
for  multiple  crews  and  longer  missions.  These  provided  the  Soviets  with  valuable  experience  in 
extended  stays  in  space  providing  logistics  support  and  crew  transportation  to  the  space  stations. 
The  third  generation  Soviet  space  station  was  the  Mir  which  was  first  occupied  in  1986  and 
remained  in  orbit  15  years.  It  was  107  feet  long  by  90  feet  wide  and  weighed  an  estimated  135 
tons  when  completed.  The  Mir  provided  valuable  research  and  information  on  long-term 
habitation  in  space.  It  also  became  the  stepping  stone  for  the  ISS  and  its  future  crews  at  the  end 
of  its  operational  life. 
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2.1.2  Skylab 

The  United  States  launched  its  first  space 
station,  Skylab,  in  1973  with  plans  to  keep  it  in 
operation  well  into  the  1980s  with  support  flights 
from  the  new  space  shuttle  (Figure  5).  It  was 
launched  on  14  May  1973  and  was  occupied  by 
three  separate  crews  that  year.  The  original  plan 
was  to  park  it  in  a  higher  orbit,  shut  it  down  and 
then  wait  for  the  new  Shuttle  to  resume  support 
flights  to  the  station.  Due  to  unexpected 
dynamics  during  the  first  reboost  a  second 
planned  firing  was  not  completed.  Due  to  delays 
in  the  Shuttle  development,  the  lower  orbit  and 
a  degrading  altitude  resulting  from  bigber 
than  anticipated  solar  activity;  it  reentered 
tbe  atmosphere  on  11  July  1979. 


Figure  5.  US  Skylab  Space  Station 


As  the  Shuttle  program  began  launch 

operations  in  1981,^^  it  began  to  take  experimental  laboratories  in  its  cargo  bay  into  orbit  for 
research  and  experiments — as  part  of  what  was  called  Spacelab.  While  not  a  true  space  station, 
it  allowed  the  US  to  conduct  research  in  orbit  and  develop  test  equipment  for  the  future  space 
stations. 


2.1.3  Space  Station  Freedom 

In  1984,  with  the  Shuttle  on  track,  NASA  announced  plans  for  the  next  stage  of  space 
exploration  to  be  a  space  station  that  would  support  up  to  eight  full  time  astronaut  scientists.  The 
design  and  funding  changed  multiple  times  during  the  1980s  and  eventually  ended  up  as  the 
Space  Station  Freedom  in  1988  with  Canada,  Europe  and  Japan  onboard  as  partners. 

2.1.4  Sbuttle-Mir  Program 

At  the  end  of  the  first  Bush  Administration  in  1992,  the  United  States  and  Russia  agreed 

1 

to  jointly  engage  in  space  exploration.  At  this  time  the  Space  Station  Freedom  was 
transitioning  into  the  International  Space  Station  (ISS),  and  United  States  and  Russia  were 
looking  for  ways  to  renew  cooperation  and  benefit  from  existing  space  programs.  Often  referred 
to  as  Phase  One  of  the  eventual  ISS  program,  the  Shuttle-MIR  program  provided  the  United 
States  access  to  the  MIR  and  opportunities  to  engage  in  long  duration  space  missions  and 
experimentation  (Figure  6).  Of  equal  importance  to  the  Russians,  it  provided  an  influx  of  badly 
needed  revenue  (in  excess  of  $400M)  to  continue  and  expand  the  MIR  program. 


“NASA’s  Space  Station  Program:  Evolution  of  Its  Rational  and  Expected  Uses,”  Marcia  Smith,  Congressional 
Research  Services,  20  April  2005. 

Russian  Federation  Agreement  Between  The  United  States  Of  America  And  The  Russian  Federation  Concerning  Cooperation  In  The 
Exploration  And  Use  Of  Outer  Space  For  Peaceful  Purposes  (Signed  at  Washington  D.C.  on  June  17,  1992,  Proclaimed  on  June  17  ,  1992) 
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Figure  6.  US  Shuttle  Docked  with  the  Russian  MIR  Space  Station 


The  initial  cooperative  program  negotiated  in  1992  had  a  single  American  astronaut 
visiting  the  MIR  and  two  cosmonauts  joining  a  Shuttle  mission.  By  1993,  the  United  States  had 
announced  revised  plans  for  ISS,  and  the  program  was  expanded.  The  new  program  allowed  the 
United  States  to  invest  in  the  MIR  construction  which  allowed  for  the  launch  and  integration  of 
new  modules,  the  Spektr  and  the  Priroda.  Both  were  modules  previously  begun  prior  to  the 
collapse  of  the  Soviet  Union  and  both  had  initially  been  designed  to  accommodate  some  military 
missions  (surveillance).  While  NASA  had  little  to  do  with  the  design  of  the  MIR,  it  did  allow 
NASA  to  research  the  long  term  effects  of  micro-gravity  on  astronauts,  gain  experience  on 
spacewalks,  allow  testing  and  research  of  new  equipment,  gain  valuable  experience  in  docking 
(Shuttle  and  Soyuz  capsules  with  MIR)  and  learn  critical  lessons  about  day  to  day  operation  of 
long  term  space  assets  in  orbit. 

The  program  began  in  February  1994  with  the  inclusion  of  Cosmonaut  Sergei  Krikalev 
on  board  STS-60  for  a  nine-day  Shuttle  mission.  The  first  Shuttle  mission  to  MIR  came  in  1995, 
and  Shuttle  support  ended  in  1998.  During  this  time,  seven  astronauts  performed  long  duration 
flights  on  the  MIR  (up  to  six  months)  which  provided  valuable  information  for  systems 
engineering  (SE)  requirements  generation  of  the  ISS.  They  also  spent  significant  time  in  Russia 
training  and  working  with  the  Russian  system  engineering  staff. 

While  the  program  is  hailed  as  a  major  success  and  valuable  source  of  data  for  the  ISS, 
much  of  the  valuable  information  was  learned  the  hard  way.  Although  it  would  be  incorrect  to 


In  the  mid-1990s  with  the  return  of  US-Russian  cooperation  in  space,  NASA  agreed  to  provide  funds  to  complete 
the  Spektr  and  Priroda  modules  in  exchange  for  having  600  to  700  kg  of  US  experiments  installed. 
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say  that  the  missions  were  totally  suceessful  and  the  US  experienee  was  flawless,  it  painted  a 
elear  pieture  of  the  risks  involved  in  international  spaee  stations  and  their  development. 

■  The  marriage  of  NASA  with  the  Russian  spaee  program  felt  to  many  to  be  a 
foreed  marriage  at  best  in  the  beginning.  It  was  a  major  eultural  shook  for  the 
NASA  astronauts,  engineers  and  managers  to  integrate  with  the  former  Soviet 
bureauoraoy  and  its  systems  engineering  establishment.  Information  was  power 
in  the  Russian  system,  so  dooumentation  and  sharing  of  information  was 
constrained.  The  Russians  had  similar  difficulties  learning  and  understand  the 
engineering  techniques  and  emphasis  of  their  American  counterparts. 

■  Although  NASA  had  significant  experience  in  multi-national  projects  the  level  of 
support  and  integration  required  to  form  the  partnership  with  Russia  was 
overwhelming.  This  was  exacerbated  by  the  condition  of  emergence  from  the 
Soviet  era  and  the  mammoth  political  and  economic  change  occurring  in  Russia. 

■  In  most  NASA  international  projects  English  was  the  primary  language  of  the 
project.  With  the  initiation  of  the  Russian  partnership  that  was  the  accepted 
principle  however  it  was  not  practical  to  have  English  as  the  primary  language. 
Most  of  the  NASA  professionals  couldn’t  speak  Russian  and  few  Russians  spoke 
English,  which  caused  communication  problems  across  the  board — even  with 
interpreters.  In  addition  to  basic  language,  the  teams  needed  to  agree  on  a 
fundamental  engineering  and  project  management  lexicon. 

■  In  the  difficult  economic  environment  of  the  mid- 1 990 ’s  in  Russia,  the  Russian 
space  industry  was  encouraged  to  seek  “off-budget”  resources.  This  also  evolved 
into  unique  payment  scenarios  where  cosmonauts  were  compensated  for  specific 
mission  tasks.  This  raised  significant  differences  in  approach  to  crew  operations 
and  at  times  caused  confusion  in  plans  and  motivations  for  activities. 

■  In  1997,  an  oxygen-producing  canister  (the  same  as  being  proposed  for  the  ISS) 
caught  fire  aboard  the  Mir  Space  Station  due  to  a  quality  problem  during 
production  (apparently  a  piece  of  latex  glove  was  accidently  left  in  the  canister 
The  resulting  fire  and  smoke  seriously  compromised  the  station’s  environment 
and  scalded  one  of  the  cosmonauts,  who  attempted  to  put  it  out  with  a  water- 
based  fire  extinguisher. 


DragonFly:  NASA  and  the  Crisis  Aboard  MIR.  Bryan  Burrough,  Harper  Collins  Publishers. 
“Latex  Glove  Sparked  Fire  Aboard  MIR  Space  Station”,  Michael  Brooks,  The  Guardian.  1997. 
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■  Also  in  1997,  the  Russians 
experimented  with  a  manual  doeking 
system  for  the  Progress  in  hopes  that 
it  would  allow  them  to  avoid  using 
an  expensive  automated  system  that 
had  proven  sueeessful  on  past 
missions.  On  one  attempt,  they  lost 
control  of  the  Progress  and  it  barely 
missed  the  station.  A  few  months 
later,  they  attempted  a  similar 
experiment  and  this  time  the 
Progress  hit  the  station  and 
punctured  the  Spektr  module.  This 
caused  significant  damage,  a  total 
loss  of  power  and  control  and  initial 
decompression  (Figure  7).  Note  that 
partial  power,  control,  and  cabin 
pressure  were  later  recovered  and 
did  not  affect  crew  survivability. 


Figure  7.  Damage  to  the  Soviet  MIR 
from  Docking  Accident 


2.2  Space  Station  Freedom  Redesign 

1  ”7 

On  June  17,  1993,  President  Clinton  announced  that  he  was  accepting  the  advice  of  a 
special  blue  ribbon  panel  and  directing  NASA  to  downsize  the  planned  Space  Station  Freedom 
(SSF)  to  save  budget.  He  directed  NASA  to  work  with  the  US’s  International  Partners  (IP)  to 
develop  this  reduced  cost,  scaled  down  version  of  the  original  Space  Station  Freedom.  By  the 
end  of  1993,  the  space  station  had  a  new  preliminary  design  and  the  partners  had  invited  Russia 
as  a  major  contributor  and  partner.  The  name  Space  Station  Freedom  had  been  dropped  and  it 
became  the  International  Space  Station. 

2,2,1  Budget 

The  primary  reason  driving  the  redesign  of  the  Space  Station  Freedom  was  escalating 
cost  and  a  desire  by  the  Administration  and  Congress  to  reduce  NASA’s  budget.  At  the  time  in 
1993,  the  cost  to  design  build  and  launch  SSF  was  $3 IB  with  estimated  operational  costs  of 
$100B  over  its  30-year  lifespan.^*  The  new  station,  chosen  by  President  Clinton,  had  an 


“Space  Station  Redesign  Decision  Reduces  Costs,  Preserves  Research,  Ensures  International  Cooperation,” 
Executive  Office  of  the  President  news  release,  17  June  1993 

“NASA  Unsure  If  Redesigned  Space  Station  Is  Viable,”  by  Warren  E.  Leary,  The  New  York  Times,  April  23, 
1993. 
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estimated  cost  of  $12. 8B  over  the  first  five  years  (develop/launch)  and  $16. 5B  for  operational 
costs  during  deployment  and  a  reduced  lifespan  of  just  ten  years  after  its  assembly  in  space.  At 
this  point  in  time,  SSF  had  already  cost  $9B  and  it  was  hoped  much  of  its  technology  and 
systems  could  be  reused  on  the  new  design.  An  additional  but  enormously  significant  constraint 
was  the  direction  from  the  Administration  that  the  ISS  program  spending  profile  would  be 
essentially  flat,  capped  at  $2.1  B  per  year,  during  its  development. [Note  that  for  large 
government  funded  efforts,  not  only  are  technical  issues  the  causal  factor  of  cost  growth,  but 
when  the  funding  profile  or  “phasing”  does  not  meet  the  planned  profile,  the  cost  tends  to  grow 
and  the  schedule  likely  slips.  Thus  it  is  not  just  the  amount  of  funding,  but  when  the  project 
receives  it.]  As  a  program  management  challenge,  incorporating  a  traditional  development 
funding  curve  in  a  flat  profde  would  drive  the  ISS  program  in  many  ways. 

Despite  the  redesign  and  its  presidential  support,  the  station’s  future  was  still  in  jeopardy. 
Just  weeks  after  the  report  of  the  redesign  team  the  ISS  barely  survived  a  cancellation  vote  in  the 
Congress  by  a  single  vote.  Over  the  next  several  years,  the  program  would  continually  face 
cancellation  votes.  Although  the  margin  of  victory  continued  to  climb,  the  level  of 
Congressional  interaction  was  a  large  drain  on  program  resources. 

2,2.2  Studies/Review  Panels 

Underestimates  by  NASA  of  the  station  program's  cost  and  unwillingness  by  Congress  to 
appropriate  funding  for  the  space  station  resulted  in  delays  of  Space  Station  Freedom’s  design 
and  construction;  it  was  repeatedly  redesigned  and  rescoped.  Between  1984  and  1993  it  went 
through  seven  major  re-designs,  losing  capacity  and  capabilities  each  time.  In  January  1993, 
Vice  President  Dan  Quayle  provided  the  outgoing  President  Bush  with  the  annual  report  on  the 
us  Space  Program.  It  generally  supported  the  Space  Station  Freedom  and  gave  it  the  go-ahead 
to  continue  development.  However,  with  a  new  administration  a  few  weeks  later,  things  changed 
dramatically.  Space  exploration  had  been  a  major  emphasis  area  of  President  Bush  and  his 
predecessor.  President  Reagan.  The  new  democratic  administration  had  a  different  set  of 
priorities  and  saw  a  need  to  reallocate  the  federal  budget. 

On  March  9,  1993,  President  Clinton  directed  the  formation  of  the  Advisory  Committee 
on  the  Redesign  of  the  Space  Station.  Their  task  was  to  spend  90  days  to  redesign  the  space 
station  with  the  goal  of  reducing  costs  while  still  retaining  research  capability.  At  the  same  time, 
NASA  formed  a  team  of  45  top  NASA  engineers  and  administrators  along  with  10 
representatives  from  the  International  Partners  to  do  the  actual  designs.  The  NASA  team  was 
directed  to  develop  three  options  that  met  budget  goals,  provided  technical  and  scientific 
capability,  and  reduced  NASA  management  and  operation  costs.  The  three  options.  A,  B,  and  C 
were  targeted  to  different  development  budget  targets.  Option  A  kept  much  of  the  Freedom 
design  but  added  an  existing  large  spacecraft  bus  as  an  initial  building  block.  Option  B  was  an 
optimized  version  of  the  Space  Station  Freedom  design.  Option  C  was  a  major  deviation  that 


“Space  Station  Will  Not  Be  Cancelled,”  Audrey  Leath,  American  Institute  of  Physics,  June  18,  1993. 

A  flat  funding  profile  while  simple  from  a  budget  viewpoint,  has  little  correlation  with  the  actual  development  and 
production  requirements.  It  causes  the  program  managers  to  make  sub-optimal  decisions  which  normally  result  in 
schedule  delays  and  cost  increases. 

“Final  Report  to  the  President  on  the  US  Space  Program,”  The  National  Space  Council,  January  1993. 
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utilized  a  very  large  eore  module  similar  to  the  Skylab.  This  option  would  require  a  new  Shuttle- 
C  launeh  vehiele  to  lift  the  Station  eore.  The  team  reeommended  Option  A  as  the  best  solution 
and  that  became  the  basis  of  negotiations  with  Russia.  Over  time  and  with  the  addition  of  Russia 
many  of  the  aspects  of  the  Option  A  were  dropped.  The  ISS  today  is  much  more  the  Freedom 
configuration. 

2,2.3  Changes  from  SSF  to  ISS 

2.2.3. 1  International  Partners  and  Management 

The  Reagan  plan  for  the  Space  Station  Freedom  intended  that  it  would  be  a  permanently 
crewed  space  station  built  by  the  US,  operated  by  the  US,  but  with  added  capabilities  from  its 
IPs.^^  The  US  goal  would  be  that  the  IPs  would  not  be  on  the  critical  path  and  their  contributions 
would  be  enhancements.  As  the  definition  of  the  ISS  assembly  task  grew  it  became  obvious  that 
the  Canadian  Canadarm2  would  play  a  critical  role  in  the  station  operations  and  assembly.  The 
initial  invitation  to  participate  from  President  Reagan  was  to  the  US  Allies.  This  invitation  was 
answered  by  Europe  (the  European  Space  Agency,  ESA),  Japan  (NASDA,  later  renamed  JAXA) 
and  Canada  The  Canadian  Space  Agency  (CSA). 

With  the  new  program  and  its  IPs,  the  US  did  retain  its  role  as  the  integrator  (with  Boeing 
as  the  prime  US  Contractor),  but  the  IPs  were  responsible  for  the  development  and  long  term 
support  of  their  modules  and  were  now  major  investors  and  equal  partners  in  the  ISS.  In  fact  the 
management  of  the  ISS  has  been  devised  in  the  Memorandums  of  Understanding  (MOU’s)  to 
utilize  bilateral  relationships  to  facilitate  the  development  of  the  elements  and  a  multilateral 
framework  to  integrate  the  overall  operations  of  the  ISS.  In  the  multilateral  framework  the  stated 
goal  was  consensus  decision  making  although  the  US  was  empowered  to  make  decisions  if  no 
consensus  could  be  reached.  As  the  configuration  evolved,  the  IP  contributions  (particularly 
those  from  the  Russians)  became  increasingly  more  important  to  the  critical  path  of  ISS 
assembly.  This  situation  required  a  much  more  integrated  plan  of  testing,  assembly  and 
operations.  It  also  led  to  schedule  impacts  as  partners  had  budget  and  development  challenges. 

Under  the  new  ISS,  NASA  was  essentially  the  managing  partner,  with  each  board 
chaired  by  the  NASA  representative.  In  cases  where  consensus  could  not  be  reached,  the  NASA 
representative  had  the  right  to  make  a  decision  for  the  board;  however,  this  right  was  rarely  used 
in  practice.  Nothing  in  the  ISS  arrangements  conferred  upon  NASA  the  right  or  ability  to 
compel  another  IP  to  take  specific  actions  against  its  interests;  therefore,  occasions  were  rare  in 
which  it  was  efficacious  for  NASA  to  make  unilateral  decisions.  This  was  a  significant 
challenge  to  the  systems  engineering  process,  as  NASA  had  to  negotiate  processes  with 
individual  partners  and  across  the  entire  partnership.  In  a  systems  engineering  aspect  several 
architectural  decisions  were  successfully  implemented  across  most  of  the  elements.  Since  the 
partnership  agreement  with  Russia  allowed  the  use  of  existing  or  heritage  equipment  some  of 
those  architectural  agreements  were  not  extended  to  the  Russian  elements. 


“Structuring  Future  International  Cooperation:  Learning  from  the  ISS,”  L.  Cline,  P.  Finarelli,  G.  Gibbs,  I.  Pryke, 

“Lessons  Learned  and  Recommendations  on  International  Participation  from  the  International  Space  Station 
Program,”  Daniel  V.  Jacobs  and  Michael  J.  See,  Lyndon  B.  Johnson  Space  Center,  Sept.  2004. 
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The  inclusion  of  the  Russians  brought  major  changes.  Several  changes  were  cultural, 
since  the  Russian  approach  to  space  systems,  engineering  and  operations  was  different  than  that 
of  the  US  and  its  contractors.  The  source  of  the  differences  came  with  respect  to  approaches  to 
systems  design.  Basically,  the  Russians  tended  to  employ  a  very  evolutionary  approach  that 
drew  heavily  on  heritage  designs,  whereas  NASA  and  ESA  engineers  were  much  more  inclined 
toward  clean  sheet  designs  which  incorporate  latest  technologies.  So,  there  were  differences  in 
the  details  of  the  respective  systems  engineering  approaches  driven  by  these  distinctive 
approaches  to  systems  design.  Furthermore,  the  other  IPs,  foreign  countries  with  different 
languages,  operated  more  like  the  US.  Many  of  their  engineers  and  managers  were  US-trained 
and  educated,  and  their  aerospace  firms  had  worked  on  US  projects  or  with  US  contractors.  That 
was  not  the  case  with  the  majority  of  the  Russian  government  and  private  contractors.  Most  of 
the  Russian  contractors  were  cold  war  remnants  of  the  Soviet  Union  and  were  struggling  to 
remain  in  business.  Furthermore,  most  of  their  engineers  had  little  contact  with  western  firms  or 
practices — despite  some  contact  through  professional  organizations  and  journals.  Finally,  the 
Russians  as  a  new  team  member  did  not  integrate  as  easily  as  European,  Canadian,  or  Japanese 
partners,  who  had  worked  with  NASA  for  years. 

2. 2. 3. 2  Orbit 

A  major  change  for  the  ISS  was  the  decision  to  place  the  station  in  a  51.6  degree  orbit, 
the  inclination  the  Russians  achieve  by  launching  due  east  from  Baikonour.  Prior  launches  from 
the  Kennedy  Space  Center  were  frequently  at  an  inclination  of  28.5  degrees  to  the  equator 
(which  allows  for  the  maximum  delta-v  imparted  to  the  launch  vehicle  by  the  rotation  of  the 
Earth  due  to  a  due  east  launch),  though  the  Shuttle  had  flown  several  different  inclinations  prior 
to  the  ISS  flights.  This  orbit  provided  safe  launches  over  water  into  an  orbit  that  the  Soviets 
could  not  reach  without  incurring  a  substantial  payload  penalty.  Changing  the  orbital  inclination 
to  51.6  degrees  allowed  the  Russian  launch  facilities  to  provide  support  to  the  ISS. 

At  the  time,  NASA  was  sensitive  that  future  groundings  of  the  Shuttle  fleet  due  to 
accidents  (Challenger  had  just  occurred  in  1986)  would  severely  impact  the  ISS,  and  the  possible 
use  of  a  Russian  capsule  for  rescue  or  backup  crew  transport  was  a  valuable  asset  to  bring  to  the 
team.  The  downside  to  this  option  was  the  reduction  of  Shuttle  lift  capability  (almost  11,500 
pounds  out  of  its  maximum  capability  of  55,000  pounds).  Eater  the  Shuttle  program  regained 
much  of  this  lift  through  the  development  of  a  “super  lightweight”  version  of  the  Shuttle 
External  Tank  and  other  weight  savings  options.  This  dissimilar  redundancy  of  launch  vehicle 
was  validated  with  the  future  repeated  use  of  the  Progress  and  Soyuz  vehicles  after  the  Columbia 
accident  and  the  grounding  of  the  Shuttle  fleet  in  2003.  Fourteen  successive  Russian  crew  and 
supply  missions  reached  the  ISS  before  the  shuttle  returned  to  flight. 

Changing  the  orbital  inclination  was  a  huge  SE  challenge.  It  impacted  key  ISS  design 
elements  such  as  power  and  thermal  subsystems,  orbital  debris  protection,  and  STS  operations. 
Moreover,  none  of  the  subsystems  were  redesigned  to  maximize  operation  in  the  new  orbit.  The 
decision  was  taken  that  in  order  to  save  design  costs,  much  of  the  hardware  designed  for  a  28 
degree  orbit  would  be  flown  ‘as  is’  in  the  higher- inclination  orbit.  The  change  increased  the 
number  of  assembly  flights,  restricted  launch  windows  throughout  the  year  and  per  launch 
opportunity.  Changing  the  orbital  inclination  was  a  major  decision  that  ended  up  being 
negotiated  at  the  Vice  Presidential  Eevel  (A1  Gore  and  Viktor  Chernomyrdin).  This  decision 
salvaged  much  of  the  design  up  to  that  point,  but  created  major  operational  complexities  that  are 
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still  being  experienced  today,  and  that  indeed  drive  the  size  and  cost  of  the  workforce  needed  to 
operate  and  maintain  the  ISS. 

2,3  NASA  Systems  Engineering  Environment 

2,3,1  NASA  Management  Approach 

NASA  had  the  task  of  leading  a  sixteen-country  international  team  through  the  ISS 
system  development,  module  production,  visiting  vehicle  fleet  scheduling  and  integration,  on- 
orbit  construction,  and  the  long-term  station  operation.  Each  agency  negotiated  and  signed 
detailed  agency-specific  Memoranda  of  Understanding  (MOUs)  that  defined  partner 
contributions,  payments  for  support,  and  operational  responsibilities.  Operational  control  of  the 
ISS  in  entirety  was  to  be  enabled  from  Houston  and  Moscow,  while  control  of  payloads  and 
some  partner  module  systems  were  planned  for  partner  auxiliary  sites  such  as  St.  Hubert  and 
Huntsville.  As  shown  in  Figure  8,^^  multiple  control  centers  and  launch  sites  are  in  use. 
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Figure  8.  NASA  and  International  Partner  Operations  Scope 

In  order  to  appreciate  the  effectiveness  of  the  post  1993  Space  Station  redesign 
management  approach,  a  brief  background  of  the  Space  Station  Freedom  period  is  useful.  The 
original  structure  of  the  Space  Station  Freedom  systems  engineering  effort  involved  several 
“levels”.  The  Freedom  engineering  hierarchy  was  organized  as  much  for  political/congressional 
funding  reasons  as  for  any  other  reason,  and  this  structure  led  to  significant  integration  issues, 
due  to  its  wide  geographic  spread  and  the  decoupled  nature  of  the  financial  oversight  of  the 
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program.  Level  1  was  housed  at  NASA  headquarters  in  Washington,  DC.  It  was  not  direetly 
involved  in  the  day-to-day  engineering  effort,  and  instead  handled  most  of  the  politieal  interfaees 
and  the  highest-level  program  funding  deeisions.  Level  2  was  a  speeially  ereated  NASA  eenter, 
housed  in  leased  offiee  spaee  in  Reston  Virginia,  separate  from  both  HQ  and  the  NASA  field 
eenters.  Level  2  was  explieitly  designed  to  be  a  systems  engineering  eenter  for  the  Freedom 
program.  However,  Level  2  was  not  empowered  to  eontrol  budgets  of  individual  projeet  offiees 
(the  work  paekages)  at  the  field  eenters,  thus  it  had  virtually  no  leverage  over  the  engineering 
projeets  it  was  supposed  to  integrate. 

Level  3  handled  the  detailed  engineering  of  the  subsystems  and  the  modules.  Eaeh 
subsystem  and  eaeh  module  had  a  system  development  manager  (SDM)  and  a  system  integration 
manager  (SIM).  The  power  generation  system  was  assigned  to  the  Lewis  (later  renamed  Glenn) 
Researeh  Center,  the  environmental  eontrol  and  life  support  system  was  assigned  to  Marshall 
Spaee  Flight  Center  (MSFC),  most  other  systems  and  subsystems  were  assigned  to  the  Johnson 
Spaee  Center,  the  integration  of  the  modules  and  payload  aeeommodations  were  assigned  to  the 
Marshall  Spaee  Flight  Center,  and  the  speeial  dexterous  human-like  robotie  system  ealled  the 
Flight  Telerobotie  Servieer  (FTS)  was  assigned  to  the  Goddard  Spaee  Flight  Center.  There  was 
tremendous  politieal  pressure  to  have  major  responsibilities  assigned  in  the  different 
eongressional  distriets:  thus  it  was  ambiguous  in  many  oases  to  know  who  was  aotually  in 
oharge. 

As  an  example  of  the  oonfusion  that  oould  ensue  from  suoh  organizational  struoture, 
oonsider  the  distribution  of  eleotrioal  power.  The  seoondary  power  system  was  managed  at  JSC 
as  a  subsystem.  Its  interfaoe  with  payloads  ooourred  at  the  interfaoe  to  raoks  within  the  US  lab 
and  inside  modules  developed  by  ESA  and  by  NASDA  (later  named  JAXA).  The  eontrol  of  the 
power  distribution  was  aooomplished  through  the  data  management  system  (DMS)  arohiteoted  at 
JSC,  but  programmed  in  the  individual  field  eenters  in  individual  Tier  1  oontrollers  (more  on 
Tier  1  later).  At  varying  meetings,  it  was  olaimed  that  the  oommand  and  eontrol  of  the  power 
management  at  the  payload  raek  interfaoe  was  the  responsibility  of  the  power  subsystem  team, 
the  payloads  team,  the  lab  module  team,  and  the  data  management  team.  Contraotors  working 
for  the  payloads  oommunity  developed  the  obligatory  Payloads  to  Eleotrioal  Power  Subsystem 
(EPS)  Interfaoe  Requirements  Dooument  (IRD).  At  the  same  time,  oontraotors  working  on  the 
power  subsystem  developed  the  Eleotrioal  Power  Subsystem  to  Payloads  Interfaoe  Requirements 
Dooument.  Neither  was  developed  with  the  oooperation  of  the  other  oontraotor  or  eenter.  The 
Eab  team  developed  IRDs  to  both  groups  that  enoapsulated  the  eleotrioal  interfaoe  eontrol  with 
the  Eab  eontrol  prooessor  in  oharge.  The  Data  Management  System  (DMS)  team  developed 
independent  IRDs  to  the  Eab,  to  payloads,  and  to  EPS,  and  they  in  turn  developed  independent 
IRDs  to  the  DMS,  with  suoh  routine  matters  as  olosing  eleotrioal  oirouits  as  one  of  the  major 
funotions  of  the  interfaoe. 

Worse,  in  the  early  days  of  Ereedom,  the  oontraot  struoture  required  that  the  oontraotors 
deliver  suoh  doouments  by  certain  drop  dates.  The  technical  maturity  of  such  contractually 
mandated  books  was  not  specified  in  the  delivery  dates:  only  the  structure  of  the  document  and 
key  contractually-mandated  legal  text  was  specified.  Thus,  scores  of  such  IRDs  flowed  around 
the  program  with  boilerplate  preamble  text  and  acronym  lists,  sandwiched  around  technical 
sections  that  were  largely  filled  with  “TBD”.  It  was  easy  to  get  decoupled,  and  to  stay  that  way 
for  long  periods.  Eevel  2  had  no  power  to  order  the  elimination  or  merging  of  any  duplicate 
documents.  Erom  the  scant  technical  content  that  did  emerge  from  the  myriad  boilerplate 
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documents,  the  emerging  command  and  control  team  found  at  least  seventeen  command  names 
for  the  act  of  activating  a  switch,  including  command  names  such  as  “On”,  “Toggle”,  “Enable” 
“Switch”,  “Power”,  “Power  ON”,  and  “Set  On”. 

The  eoncept  of  Level  2  and  work-paekages  exemplified  how  not  to  eonduet  systems 
engineering  on  a  complex  system.  As  exemplified  above,  the  Level  2  management  had  no 
eontrol,  speeifically  budgetary  eontrol,  over  the  Level  3  Work  Packages.  “Influence”  proved  not 
to  be  a  sufficient  integrating  lever.  It  was  elear  at  that  point  that  a  single  lead  center  with 
designated  program  management  authority  and  control  as  well  as  resident  engineering 
horsepower  was  an  absolute  neeessity  on  a  program  this  large,  eomplicated  and  multi-national. 
The  Johnson  Space  Center  became  the  lead  program  management  and  SE  eenter  following  the 
1993  redesign  (the  post-Spaee  Station  Lreedom  era).  In  that  role,  they  are  supported  by  Boeing, 
who  served  as  the  integrating  contractor  and  prime  support  eontractor.  Boeing  has  procured  and 
developed  several  of  the  key  modules  and  systems.  Boeing  also  provides  overall  hardware- 
software  integration  and  sustaining  engineering.  Along  with  Boeing  are  hundreds  of  large  and 
small  contraetors  providing  key  subsystems,  teehnical  supports  and  logistics  services.  Within 
NASA,  these  eontraetors  are  engaged  through  normal  contracting  channels  and  partieipation  on 
Integrated  Product  Teams  (IPTs). 

Boeing  played  a  eritical  role  on  this  team  as  the  lead  system  engineer  for  the  program. 
Boeing  provided  the  experience  to  eo-lead  the  IPTs  with  NASA  and  exeeute  the  SE  management 
that  was  a  major  ehallenge  on  this  program  due  to  the  multi -partner  integration.  It  was  a 
challenging  role,  since  Boeing  eould  not  offieially  negotiate  with  other  countries  and  often  had  to 
provide  the  technieal  lead  while  NASA  provided  offieial  signature  on  detailed  international 
agreements  known  as  “Protocols”. 

The  overall  Program  team  is  managed  through  an  ISS  Control  Board  Structure,  as  shown 
in  Ligure  9.  The  ISS  team  uses  top-level  control  boards  and  panels  to  manage  the  ISS  hardware 
and  software  configuration  along  with  any  operational  produets.  At  the  very  top  of  the  process  is 
the  Space  Station  Control  Board  (SSCB)  that  manages  the  multilateral  control  of  the 
configuration.  A  NASA  Space  Station  Program  Control  Board  exereises  eontrol  over  the  several 
layers  of  more  detailed  ISS  subsystem  eontrol  boards  assoeiated  with  the  US  elements.  This 
proeess  is  also  integrated  with  the  Spaee  Shuttle  control  boards.  Each  partner  utilizes  a  similar 
control  mechanism  for  their  elements. 
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Boards  Integrate  International  Partner  and  Contractor  Teams  within  their  Disciplines 


Figure  9.  Systems  Engineering  Integration  Boards 


19 


2.3.2  NASA  Center  Approaches 

NASA  has  10  major  centers  within  its  organization  and  in  theory  they  are  of  one  mind  on 
systems  engineering  as  it  relates  to  major  projects.  As  an  agency,  NASA  maintains  Systems 
Engineering  proeess  guidanee  and  good  praetiees  as  doeumented  in  its  NASA  System 
Engineering  Handbook.  Despite  this  set  of  ageney-level  proeess  requirements,  the 
interviewees  eommented  that  each  NASA  center  had  a  legaey  systems  engineering  (SE)  proeess 
that  was  at  times,  slow  to  conform  to  the  ageney  approaeh.  Additionally,  several  reported  that 
the  SE  proeesses  were  driven  by  the  lead  SEs,  who  tended  to  dominate  the  resident  programs. 
The  approaehes  are  also  different  based  on  the  systems  being  developed  and  operated,  whieh 
allows  for  a  tailoring  of  the  approaeh.  In  the  ease  of  the  ISS,  this  was  exaeerbated  by  the 
inelusion  of  the  international  partners  whose  SE  approaehes  differed  signifieantly. 

26 

In  a  1969  speeeh  prior  to  the  ISS  and  prior  to  beeoming  NASA  Administrator,  Robert 
Eroseh  eommented  on  strict  adherence  to  mandated  SE  techniques  and  bureaueraey: 

“I  believe  that  the  fundamental  difficulty  is  that  we  have  all  become  so  entranced 
with  technique  that  we  think  entirely  in  terms  of  procedures,  systems,  milestone 
charts,  PERT  diagrams,  reliability  systems,  configuration  management, 
maintainability  groups  and  other  minor  paper  tools  of  the  ‘system  engineer’  and 
manager.  We  have  forgotten  that  someone  must  be  in  control  and  must  exercise 
personal  management,  knowledge  and  understanding  to  create  a  system.  .  .  . 
Systems,  even  very  large  systems,  are  not  developed  by  the  tools  of  systems 
engineering,  but  only  by  engineers  using  tools.  ” 

2.3.3  System  Engineers  and  the  Experience  Chain 

A  major  issue  of  any  program,  espeeially  one  like  the  ISS  going  on  two  deeades,  is  how 
to  recruit,  develop,  and  retain  quality  system  engineers.  In  faet,  NASA’s  human  spaeeflight 
programs  are  usually  generational  programs.  NASA  has  to  manage  the  workforce  over  deeades 
while  ramping  up  for  new  programs,  maintaining  ongoing  programs  and  shutting  down  long¬ 
term  programs.  In  the  ISS  ease,  the  ehallenge  is  espeeially  difficult. 

■  The  initial  workforee  was  a  mix  of  experienee,  some  dating  all  the  way  to  Apollo, 
Skylab  and  Apollo-Soyuz.  Most  of  the  staff,  however,  eame  from  the  Spaee 
Shuttle,  Spaee  Station  Ereedom,  and  Shuttle-Mir  programs.  While  the  ISS 
program  has  been  relatively  sueeessful  to  date,  it  has  been  under  eonstant  attack 
due  to  its  sehedule  and  budget  issues,  along  with  eompetition  from  other 
programs  (inside  and  outside  of  NASA).  This  does  not  ereate  a  stable  long-term 
work  environment  for  some  engineers. 

■  Many  of  the  engineers  desire  eareer  progression  either  in  management  or  to  other 
teehnical  areas  or  programs.  This  tends  to  eneourage  engineers  to  leave  the 

NASA  System  Engineering  Handbook,  NASA/SP-2007-6105 

“A  Classic  Look  at  Systems  Engineering,”  Bob  Frosch,  Asst.  Secretary  of  the  Navy  for  RDT&E,  speech  to  the 
IEEE  Group  on  Aerospace  and  Electronic  Systems  their  international  conference  in  New  York,  26  March  1969. 

PERT  is  Program  Evaluation  Review  Technique 
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program  and  seek  other  opportunities.  This  is  particularly  exacerbated  in  very 
long  term  programs  like  the  ISS. 

■  While  not  unique  to  ISS,  over  the  program’s  history,  many  of  the  traditional 
NASA  government  positions  and  areas  of  responsibility  have  been  absorbed  by 
contractors  in  attempts  to  reduce  cost.  While  this  study  does  not  allege  any 
difference  between  a  practicing  government  SE  as  opposed  to  a  contractor  SE — 
there  is  a  difference  driven  by  job  descriptions  and  responsibilities.  As  the 
government  SEs/engineering  positions  decline,  the  remaining  personnel  have  less 
opportunity  to  “start  at  the  bottom”  and  do  detailed  engineering  over  a  full  career. 
Rather,  they  often  see  their  administrative  and  management  responsibilities  leave 
them  little  opportunity  to  learn  and  to  hone  their  engineering  skills.  At  the  same 
time,  more  and  more  of  the  engineering  and  system  engineering  responsibilities 
are  assigned  to  the  contractor.  This  makes  it  very  difficult  for  the  government  SE 
to  gain  in-depth  SE  experience. 

■  During  the  space  station  redesign  a  decision  was  made  to  dramatically  modify  the 
systems  engineering  and  integration  aspect  of  the  program.  Rather  than  the 
Ereedom  model  of  the  government  team  (with  a  support  contractor)  providing 
SE&I,  the  team  recommended  selecting  a  single  prime  contractor  to  manage  those 
functions  across  the  multiple  EIS  elements  and  to  provide  support  to  the 
integration  with  the  partners.  This  change  was  based  on  the  potential  cost  savings 
but  also  to  simplify  what  the  panel  felt  was  a  confusing  organizational  structure 
and  diffuse  accountability.  Depending  on  the  level  of  the  division  of  labor 
between  NASA  and  the  Prime  this  can  lead  to  dissatisfaction  with  engineers  who 
desire  a  more  “hands  on”  level  of  participation  in  the  SE  process.  Although  it  may 
depend  on  who  you  ask,  with  many  NASA  ISS  engineers  believing  that  the  IPT 
structure  made  the  system  a  bit  more  “badge-less”  between  the  Prime  and  the 
government. 

Multiple  studies  have  researched  the  traits  that  make  a  good  systems  engineer  and  the 
environment  that  is  required  to  nurture  them.  A  recent  study^^  from  the  Aerospace  Corporation^^ 
investigated  why  certain  organizations  were  able  to  develop  a  steady  stream  of  qualified  systems 
engineers.  In  this  study.  Dr.  Davidz  identified  five  foundational  elements  that  support  a  system 
engineering  development  environment: 

1.  Componential  element:  this  element  describes  those  aspects  that  are  considered  in 
systems  thinking,  such  as  systems  objectives,  elements,  and  domain.  This  considers 

-5  A 

components  such  as  political,  organizational,  economic  and  technical. 


“Developing  the  Next  Generation  of  Systems  Engineers”  by  Dr.  Heidi  Davidz,  Aerospace  Corporation  2006 

Aerospace  Corporation  is  a  federally  funded  research  and  development  center  (FFRDC)  for  the  United  States  Air 
Force  and  the  National  Reconnaissance  Office  to  support  all  national-security  space  and  missile  programs. 
They  have  provided  independent  technical  and  scientific  research,  development,  and  advisory  services  to  national- 
security  space  and  missile  programs  since  1960. 

“Enabling  Systems  Thinking  to  Accelerate  the  Development  of  Senior  Systems  Engineers”  PhD  Dissertation,  Dr. 
Heidi  Davidz,  Massachusetts  Institute  of  Technology,  2006. 
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2.  Relational  element:  this  element  addresses  the  eonneetions,  interaetions  and 

interdependeneies  within  the  system  or  system  of  systems. 

3.  Contextual  element:  this  element  addresses  the  nested  and  embedded  natures  of  systems 

4.  Dynamic  element:  this  element  links  systems  in  time  to  the  future  and  past,  to  include 
aspects  such  as  feedback,  uncertainty,  risk  and  programmatic  “ilities.” 

5.  Modal  element:  this  element  aids  with  understanding  and  comprehension  of  the  system 
and  is  the  “how  of  systems  thinking.” 

3 1 

A  NASA  sponsored  study  focused  on  38  successful,  highly  regarded  mid-level 
system  engineers  across  the  NASA  Centers.  Despite  the  wide  dispersal  at  different  centers  with 
different  SE  environments,  the  engineers  demonstrated  the  same  basic  highly  effective 
behaviors.  These  behaviors  fell  into  five  broad  categories:  leadership,  attitudes  and  attributes, 
communication,  problem  solving  and  systems  thinking,  and  technical  acumen. 

2,3,4  Systems  Engineering  Challenges  of  the  ISS 

The  massive  scope  of  budget,  schedule,  and  technical  goals  of  the  ISS  was  daunting 
compared  to  previous  space  projects.  It  is  one  of  the  largest  international  programs  in  modem 
times  directly  involving  sixteen  nations,  well  over  100  launches  and  almost  200  space  walks 
before  the  station  will  be  completed.  From  the  beginning,  the  team  members  were  aware  that 
they  faced  three  major  system  engineering  challenges'^: 

1.  Extended  Development  Cycle:  The  NASA  team  started  on  the  initial  space 
station  program  back  in  the  1984  time  frame,  then  went  through  several  changes 
before  becoming  the  ISS  in  1994.  Initial  modules  weren’t  launched  until  late 
1998  with  final  assembly  not  scheduled  until  about  2010.  Final  shutdown  of  the 
station  is  no  earlier  than  2016.  This  creates  an  incredible  burden  of  handling 
engineering  staffs,  knowledge  retention  and  training,  management,  government 
transitions,  budget  fluctuations,  technology  maturation  and  obsolescence. 

Over  a  long  period  of  time,  public  and  Congressional  support  can  diminish,  which 
puts  incredible  pressure  on  the  team  to  make  sure  everything  works — since 
failures  are  often  rewarded  with  termination.  As  mentioned  earlier  the  ISS 
program  faced  many  cancellation  votes  in  the  Congress.  Key  analysts  and 
engineers  are  also  looking  for  challenges  and  the  opportunity  to  work  on  a  broad 
number  of  programs,  so  knowledge  management  and  experience  retention  are 
serious  issues. 

2.  Test  and  Verification:  Due  to  the  long  development  and  build  phases  (not  to 
mention  the  structural  and  size  issues  of  the  ISS),  it  is  infeasible  to  test  the  entire 
ISS  on  the  ground  prior  to  launch.  The  first  modules  were  on  orbit  prior  to  the 
completion  of  later  modules.  The  modules  and  subcomponents  must  have  high 


“NASA  Systems  Engineering  Behavior  Study,”  Christine  Williams  (NASA  HQ)  and  Mary-Ellen  Derro  (JPL), 
October  2008. 

“Systems  Engineering  Challenges  of  the  International  Space  Station,”  Mark.  D.  Jenks,  2000  NAE  Symposium  on 
Frontiers  in  Engineering. 
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reliability  and  be  able  to  work  immediately,  sinee  on-orbit  repair  options  are  often 
limited.  As  discussed  later,  new  system  test  procedures  were  developed  to  allow 
for  multi-element  integrated  testing.  Other  parts  are  designed  for  space  (such  as 
the  solar  panels)  and  thus  can’t  be  deployed  on  the  ground  for  system  checks 
without  damaging  them  or  required  expensive  special  test  fixtures.  As  will  be 
explored  later,  there  is  the  not-so-trivial  issue  that  several  modules  were  made  by 
the  International  Partners  using  different  system  engineering  approaches  with  the 
goal  of  meeting  integration  standards.  Most  of  these  modules  never  physically 
mated  until  they  were  in  low  Earth  orbit.  Finally,  a  major  issue  is  that  the  ISS 
must  be  flight  ready  with  the  first  module  and  then  with  the  addition  of  each  new 
module  or  sub-system,  operate  on  its  own  as  a  new  independent  space  vehicle. 

3.  Infrastructure  Scale  and  Complexity:  The  infrastructure  needed  to  house  the 
program  offices,  engineering  staffs,  production  facilities,  and  integration  and  test 
facilities  is  huge  and  represents  a  worldwide  investment.  NASA  made  a  large 
investment  at  the  Kennedy  Space  Center  to  perform  these  functions  and  to  stage 
major  ISS  subsystems  and  parts.  The  infrastructure  just  for  the  launch  vehicles 
and  their  support  structure  is  a  multi-billion  dollar  effort.  The  ISS  relied  initially 
on  the  Shuttle  and  the  Russian  launch  capabilities — all  major  programs 
themselves.  Eventually  European  and  Japanese  launch  capabilities  are  also 
utilized. 

2,3,5  Systems  Engineering  Process 
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The  ISS  used  a  system  engineering  process  based  on  the  classical  textbook  model  with 
four  key  elements: 

(1)  The  ISS  is  a  time-phased  development  —  the  build  schedules  for  the  ISS  components 
are  driven  by  the  launch  schedule,  which  was  initially  spread  over  a  five  year  period 
(ultimately  took  12  years  including  the  Shuttle  downtime  from  the  Columbia 
accident.). 

(2)  The  ISS  is  physically  integrated  “in  the  field”  —  the  ISS  is  assembled  on  orbit  from  its 
87  major  component  items. 

(3)  The  ISS  is  literally  built  “around  the  world”  —  major  component  items  were  built  in 
the  United  States,  Europe,  Japan,  Canada,  and  Russia,  each  of  whose  engineering 
methods  and  cultures  differ  significantly.  Because  of  this,  a  “meets  or  exceeds” 
process  was  established  to  allow  each  partner  to  use  its  own  process  standards  rather 
than  trying  to  force  adoption  of  NASA’s  process  standards.  In  this  case,  a  “meets  or 
exceeds”  evaluation  was  performed  on  foreign  deliveries  (from  ESA,  ASI,  NASDA, 
and  CSA)  with  respect  to  manufacturing  standards,  particularly  on  materials 
processes  and  EEE  parts.  With  respect  to  Russia,  the  evaluation  was  extended  to 
include  almost  all  of  the  aerospace  standards,  including  fracture  control,  human 
factors,  and  coatings. 


“System  Engineering  the  International  Space  Station,”  L.  D.  Thomas,  Proceedings  of  the  33"^“^  Space  Congress,  pp. 
5-35  through  5-44,  April  23-26,  1996. 
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(4)  The  ISS  must  function  as  a  spacecraft  during  its  assembly  -  its  crew  inhabited  the  ISS 
beginning  with  the  third  assembly  flight,  both  to  aid  in  assembly  and  conduct 
scientific  research.  The  ISS  flew  in  44  free-flying  configurations  during  the  assembly 
phase,  an  equal  number  of  shuttle-mated  unique  configurations,  and  is  comprised  of 
scores  of  smaller  flight  elements. 

This  was  a  fusion  of  the  NASA  systems  engineering  approach  (as  codified  in  the  NASA 
SE  Handbook  SP-6105)  and  the  Boeing  system  engineering  process  (which  was  also  well 
documented  and  executed).  At  program  start,  NASA  had  over  100  system  engineers  in  the 
program  office  and  Boeing  provided  300-400  systems  engineers.  Boeing  brought  a  great  deal  of 
SE  experience  plus  their  airplane  design  and  production  experience  that  NASA  lacked.  This 
allowed  Boeing  to  share  its  aircraft  experience  in  integrating  parts  and  systems  using  digital 
preassembly  techniques  to  form  computer  aided  design  (CAD)  models. 

A  key  ingredient  of  the  ISS  success  was  the  successful  integration  of  the  customer’s 
needs  into  requirements  and  specifications.  Dr.  Dale  Thomas  (former  ISS  Systems  Engineering 
and  Integration  Manager)  described  the  approach  as:^"^ 

“All  too  often,  system  engineering  preoccupies  itself  with  requirements  definition 
for  a  product.  Requirements  definition  is  a  means,  not  an  end.  For  this  reason, 
this  section  explicitly  includes  integration  in  the  title.  Indeed,  within  the  scope  of 
this  paper,  system  engineering  includes  the  development  of  a  valid  and  cogent  set 
of  requirements  and  the  verification  of  the  as  built  design  against  those 
requirements.  Hence,  system  engineering  must  provide  assurance  that  the 
product  as  designed  and  built  meets  the  customer's  stated  need;  this  is  the 
integration  half  of  the  process.  ” 

2,3,6  International  Partners 

2. 3. 6. 1  Creating  International  Partnerships 

A  major  challenge  of  the  ISS  program  was  how  to  solve  the  political,  financial,  and 
technical  aspects  of  putting  together  a  long-term  international  partnership.  Eong  before  the 
systems  engineers  from  each  country  could  sit  down  and  start  work,  agreements  on  management, 
funding,  and  issue  resolution  had  to  be  created.  While  it  was  not  easy,  NASA  eventually  worked 
out  a  process  that  accommodated  multiple  countries  with  differing  cultural  and  engineering 
approaches  to  major  program  development  and  execution.  NASA  produced  a  lessons  learned 
report  on  the  process  and  issued  the  following  recommendations: 

(1)  Early  in  the  program,  NASA  should  establish  the  legal  and  policy  framework  for  the 
partnership  that  covers  intellectual  property  rights,  liability,  dispute  resolution,  public 
affairs,  amendments,  international  and  criminal  jurisdiction,  customs  and  integration, 
and  terminations.  No  technical  program  information  should  be  included. 


“System  Engineering  the  International  Space  Station,”  L.  Dale  Thomas,  Manager  VAIT,  NASA  Space  Station 
Program  Office. 

“Lessons  Learned  and  Recommendations  on  International  Participation  from  the  International  Space  Station 
Program,”  Daniel  V.  Jacobs  and  Michael  J.  See,  Lyndon  B.  Johnson  Space  Center,  Sept.  2004. 
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(2)  As  an  evolutionary  type  program,  initial  projects  should  be  bilateral  and  relatively 
short  in  nature.  Larger  projects  requiring  multilateral  arrangements  should  come 
later. 

(3)  A  governance  model  and  agreement  must  be  established.  The  ISS  Program  was  set 
up  to  operate  using  a  board  and  panel  structure,  each  of  which  functioned  on 
consensus.  NASA  took  the  role  of  the  managing  partner,  with  each  board  chaired  by 
the  NASA  representative.  In  cases  where  consensus  could  not  be  reached,  the  NASA 
representative  had  the  right  to  make  a  decision  for  the  board;  however,  this  right  was 
rarely  used  in  practice.  The  advantages  of  this  arrangement  were  that  each  IP  had  a 
voice  and  that  this  system  allowed  IPs  to  abstain  when  it  was  not  in  their  interest  for 
cost,  schedule  or  other  programmatic  reasons.  The  drawback  was  that  the  system 
could  become  paralyzed  when  no  consensus  was  reached  on  an  issue  and  NASA 
could  not  progress  on  it  absent  the  support  of  the  dissenting  IP(s).  The  NASA  report 
noted  that  the  Russians  had  been  reluctant  to  fully  integrate  itself  into  the  board 
structure,  preferring  to  handle  most  issues  on  a  bilateral  basis  with  NASA.  All  the 
partners  have  resisted  providing  staffing  to  support  the  NASA  board  structure  to  the 
level  that  NASA  does. 

(4)  Critical  path  management  had  to  be  maintained  by  NASA  as  the  managing  partner. 
The  critical  path  had  to  be  studied  and  evaluated  from  an  integrated  program 
perspective  to  determine  the  range  of  risks.  This  would  impact  how  the  specific 
program  plans  were  made  or  altered  to  minimize  risk.  When  partner  elements  or 
capabilities  were  on  the  critical  path,  NASA  may  have  risk  contingency  plans  in  place 
(with  the  full  knowledge  of  the  IP).  This  was  a  key  issue  early  on  with  the  Russians 
delivering  the  first  two  major  modules  that  were  critical  to  attaining  initial  operational 
capability.  After  the  first  module  (purchased  by  NASA)  had  been  delivered  on  orbit, 
there  was  a  nearly  two  year  gap  to  the  next  critical  Russian  element.  In  this  case 
NASA  considered  using  a  backup  power  and  support  module  that  had  been  partially 
developed  for  another  program  (later  cancelled  when  not  required). 

2.3. 6.2  ITAR  and  shared  technology  issues 

The  International  Traffic  in  Arms  Regulations  (ITAR)  posed  a  threat  of  foreclosing 
whole  categories  of  cooperative  efforts  on  the  ISS.^^  ITAR  rules  were  designed  to  protect 
militarily  sensitive  U.S.  technologies  from  falling  into  the  hands  of  U.S.  adversaries.  But  U.S. 
allies  are  also  subject  to  them,  even  in  cases  in  which  the  law's  application  seems  to  have 
escaped  the  bounds  of  its  intent.  ITAR  regulations  apply  to  the  ISS  and  all  of  its  partners: 
Russia,  Europe,  Japan  and  Canada.  These  nations  signed  a  treaty-level  document  called  the 
Intergovernmental  Agreement,  which  sets  out  each  partner's  rights  and  responsibilities,  and 
governs  relations  in  the  station's  operation.  The  agreement  was  signed  before  ITAR  went  into 
effect  in  1999,  and  the  partners  have  debated  whether  the  treaty  takes  precedence  over  ITAR,  or 
whether  ITAR  should  govern  the  station  partners'  relations. 

The  National  Aeronautics  and  Space  Administration  (NASA)  Authorization  Act  of  2005 
(Public  Law  109-155),  required  the  creation  of  an  International  Space  Station  Independent  Safety 


“ESA  Looks  East,”  by  Peter  de  Selding,  Space  New  Business  Report,  Jul  2005 


25 


Task  Force  (IISTF)  to  assess  the  vulnerabilities  of  the  International  Spaee  Station  (ISS)  that 
eould  lead  to  its  destruetion,  eompromise  the  health  of  its  erew,  or  neeessitate  its  premature 
abandonment  and  to  report  baek  to  NASA  and  the  Congress.  The  February  2007  study 
reported  the  following: 

The  International  Traffic  in  Arms  Regulation  (ITAR)  restrictions  and  IP 
objections  to  signing  what  the  IPs  believe  are  redundant  Technical  Assistance 
Agreements  are  a  threat  to  the  safe  and  successful  integration  and  operation  of 
the  Station.  For  example,  a  contractor  workforce  comprises  a  majority  of  the 
operations  workforce  and  must  be  able  to  have  a  direct  interface  with  the  IP 
operations  team  to  assure  safe  and  successful  operations.  Their  interactions, 
ability  to  exchange  and  discuss  technical  data  relevant  to  vehicle  operation,  etc. 
are  severely  hampered  by  the  current  ITAR  restrictions. 

The  systems  engineering  impaet  of  ITAR  was  quite  simple — it  placed  a  constraint  on  the 
SE  processes  and  engineers.  Like  any  constraint  in  a  process,  it  usually  results  in  a  sub-optimal 
outeome.  At  its  simplest,  it  prevents  the  use  of  technologies  on  key  modules  or  the  interaction 
of  systems  engineering  personnel  to  develop  and  operate  systems.  On  orbit,  it  could  result  in 
certain  equipment,  proeedures,  or  full  modules  being  off  limits  to  speeifie  astronauts,  or  speeified 
equipment  eould  not  be  integrated  into  other  systems.  Obviously,  the  ISS  could  not  operate  with 
an  integrated  erew  with  those  restrietions  and  NASA  worked  within  the  limitations  of  ITAR. 

2. 3. 6. 3  Differing  SE  Approaches  among  International  Partners 

There  is  a  myth  that  seience  and  engineering  is  black  and  white — that  regardless  of  whieh 
country  does  a  project  they  all  approaeh  it  the  same.  The  NASA  expert enee  was  that  this  was 
not  true  and  that  a  significant  amount  of  planning,  organization,  and  statesmanship  was  needed  to 
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run  a  large  international  program  like  ISS.  The  NASA  lessons-leamed  report  pointed  out  the 
following  key  observations: 

■  There  are  no  standard  practices — SE  approaehes  may  differ  widely  (along  with 
management,  funding  and  scheduling  approaehes).  The  key  to  success  was  teehnieal  and 
integration  proeesses  that  were  defined  for  all  to  follow  or  else  to  integrate  with  key 
milestones.  Communieation  protocols  were  essential,  particularly  in  understanding  the 
varying  lexieons. 

■  The  ISS  had  a  single  payload  safety  panel  with  full  partner  partieipation. 

■  A  difficult,  but  key,  aeeomplishment  was  foreing  all  Partners  to  integrate  their  schedules, 
budgets,  and  development  life  cyeles.  While  each  may  have  had  different  detailed  levels, 
they  all  had  to  integrate  at  the  top  program  levels  for  discussion  and  execution, 
particularly  as  the  Space  Shuttle  was  the  launeh  vehicle  for  US,  European,  Japanese  and 
Canadian  elements. 


“Final  Report  of  the  International  Space  Station  Independent  Safety  Task  Force,”  February  2007. 

“Lessons  Learned  and  Recommendations  on  International  Participation  from  the  International  Space  Station 
Program,”  Daniel  V.  Jacobs  and  Michael  J.  See,  Lyndon  B.  Johnson  Space  Center,  Sept.  2004. 
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■  Configuration  Management  and  Control  must  be  established  early.  While  this  is  always 
an  issue,  the  ISS  had  a  different  twist  with  its  IPs.  Here,  the  IPs  as  independent  ageneies 
eould  use  the  ehange  process  to  gain  political  or  financial  leverage  by  either  not  accepting 
changes  or  not  following  procedures. 

■  There  were  some  benefits  of  having  IP  differences.  While  commonality  is  often 
preferred,  dissimilar  hardware  approaches  can  add  robustness  for  certain  critical  and 
complex  functions.  A  good  example  is  the  two  systems  for  adjusting  station 
orientation — gyros  and  thrusters. 

2.3. 6.4  The  Political  Environment 

Managing  the  disparate  political  environments  of  ah  partners  has  also  been  a  challenge. 
Ah  partners  have  differing  constituencies,  budget  cycles  and  motivations.  The  economic  issues 
in  Russia  in  the  mid- 1 990 ’s  created  significant  financial  hardships  and  gave  rise  to  commercial 
activities  that  were  not  fully  embraced  by  the  other  partners.  Many  of  the  partners  faced  political 
financial  issues  at  various  times.  One  of  the  most  notable  issues  was  the  Russian  plan  to  fly  space 
tourists  to  the  ISS.  While  this  caused  significant  strife  in  the  partnership  in  the  beginning,  the 
teams  have  learned  how  to  effectively  manage  with  this  component  as  well.  Ultimately  the  other 
partners  found  a  joint  resolution  which  would  accommodate  the  space  tourist  flights. 

Despite  several  very  high  level  differences  the  partners  have  worked  consistently 
effectively  at  the  program  level.  This  is  a  tribute  to  ah  partner  teams. 

2,3,7  Safety/Risk  approaches 

2. 3. 7. 1  NASA  Safety  Process 

NASA  has  developed  a  rigorous  safety  review  process  that  is  documented  in  their  safety 
review  process  regulation^**  for  the  overall  integrated  safety  of  the  ISS.  The  purpose  of  this  is  to 
provide  in-line  and  phased  reviews  for  the  flight  and  ground  elements  and  the  support 
equipment.  NASA  has  signed  MOUs  with  ah  international  partner  agencies'^**  including  RSA"^^ 
delegating  NASA  as  responsible  for  the  overall  integrated  safety  of  the  ISS.  In  that  role,  NASA 
provides  the  overall  certification  that  the  system  (and  its  elements)  is  safe. 

NASA  and  its  International  Partners  have  put  together  a  rigorous  process  to  manage  risk 
and  to  oversee  the  development  and  operation  of  ah  ISS  activities 

■  ISS  Mission  Management  Team;  This  senior  level  group  meets  almost  daily  to  discuss 
ongoing  ISS  operations,  upcoming  missions,  and  to  discuss  solutions  to  ongoing  or 
developing  problems.  This  not  only  includes  onsite  leadership,  but  also  coordination  and 
participation  of  partners. 


Safety  Review  Process,  International  Space  Station,  SSP  30599  Revision  B,  February  2000. 

International  Partner  specifications  are  derived  from  SSP  50021  (flight)  and  KHB  1700.7,  Space  Shuttle  Payload 
Ground  Safety  Handbook. 

The  Russian  segment  specification  is  implemented  through  SSP  50146,  NASA/RSA  Bilateral  S&MA  Process 
Requirements  Agreement. 

“Final  Report  of  the  International  Space  Station  Independent  Safety  Task  Force,”  February  2007 
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■  Safety  and  Mission  Assurance  (S&MA)  Office:  This  group  reports  directly  to  the  ISS 
program  manager  and  is  responsible  for  managing  the  ISS  safety  program.  The  group 
integrates  all  inputs  from  the  IPs  and  manages  their  safety  reviews.  It  also  manages  all 
S&MA  activities,  reviews  and  requirements  with  the  major  contractors.  Finally,  it 
supports  the  headquarters  organization  as  needed. 

■  Safety  Review  Panel:  This  group  reviews  and  approves  the  hazard  reports  and  safety 
data  packages  required  for  flight  approval.  It  assesses  the  safety  and  design  of  all  flight 
ISS  segments,  related  ISS  flight  support  equipment,  ISS  visiting  vehicles,  and  ISS 
assembly  operations. 

To  achieve  safety  and  reduce  risk,  NASA  and  the  team  have  addressed  all  elements  of  the 
SE  process  to  minimize  problems  with  the  design,  test,  production  and  operation  of  the  ISS. 
These  key  elements  were  reviewed  by  the  ISS  Independent  Safety  Task  Force‘^^: 

■  Basic  system  design  requirements  must  address  three  levels  of  risk: 

1.  Two-failure  tolerant  to  catastrophic  hazard — The  on-orbit  space  station 
must  be  designed  so  that  no  two  failures,  or  two  operator  errors,  or  one  of 
each  can  result  in  a  disabling  or  fatal  injury  or  the  loss  of  the  Shuttle  or 
ISS;. 

2.  One-failure-tolerant  to  critical  hazards— The  on-orbit  space  station  is  to  be 
designed  such  that  no  single  failure  or  single  operator  error  can  result  in  a 
non-disabling  personal  injury,  severe  occupational  illness,  loss  of  a  major 
ISS  element,  loss  of  an  on-orbit  life  sustaining  function  or  emergency 
system,  or  damage  to  the  Shuttle; 

3.  Design  for  minimum  risk — Hazards  are  controlled  by  safety  related 
properties  and  characteristics  of  the  design  rather  than  failure  tolerance 
criteria. 

■  Robust  On-Orbit  Systems:  The  design  philosophy  is  that  the  elements  must  meet  a 
two  failure-tolerance  requirement  to  avoid  catastrophic  outcomes.  Most  of  the 
major  systems  have  a  US  system  and  separate  Russian  system.  Both  agencies 
have  very  different  approaches  to  providing  these  capabilities  which  reduce  the 
likelihood  of  a  common  failure.  Most  redundant  systems  also  are  built  capable  of 
repair  or  on-orbit  replacement.  As  an  example,  there  are  four  sources  of  oxygen 
at  all  times:  the  Russian  oxygen  generator  (Elektron),  bulk  oxygen  in  tanks,  the 
US  Oxygen  Generation  Assembly  (OGA),  and  oxygen  generation  canisters. 
While  there  have  been  issues  with  each,  there  never  has  been  a  simultaneous 
failure  of  all  four. 

■  Verification  Process:  This  is  a  five-step  process  that  verifies  that  all  hardware  and 
software  meet  requirements: 

1 .  Clearly  identify  all  requirements 


“Final  Report  of  the  International  Space  Station  Independent  Safety  Task  Force  f  February  2007 
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2.  Define  the  requirement’s  elosure  strategy — verify  the  requirements  are 
met  via  inspeetion,  analysis,  demonstration  or  test. 

3.  Exeeute  the  neeessary  verifieation  aetivities 

4.  Develop  verifieation  reports/analysis 

5.  Doeument  elosure 

■  Physieal  Verifieation:  This  step  eheeks  to  ensure  that  the  parts  fit  together  and  the 
major  sub-assemblies  integrate  eorreetly.  This  step  cannot  be  accomplished  at  the 
assembly  level,  since  most  of  the  modules  and  trusses  are  not  assembled  together 
until  the  parts  are  on  orbit. 

o  When  possible,  actual  integration  checks  should  be  conducted  on  the 
ground 

o  The  process  should  develop  and  maintain  accurate  and  detailed 
measurements  of  all  parts  for  virtual  integration  checks  and  modeling 

o  The  process  should  include  3-D  and  virtual  analysis  or  mating 

o  Full  simulation  and  continuity  checks  of  all  cables,  electrical,  and  fluid 
connections  should  be  conducted  to  ensure  functionality 

2.3. 7.2  Safety  and  Off-the-Shelf  Systems 

A  major  focus  of  the  ISS  program  was  to  use  only  proven  systems  (see  page  50  for  a 
discussion  of  technology  readiness  levels)  but  still  meet  evolving  safety  requirements.  There 
were  initial  concerns  about  the  Russian  modules  being  proposed  (Zarya  and  the  Service  Module) 
since  they  were  already  partially  built  prior  to  the  final  station  design  requirements.  NASA 
safety  officials"^"^  studied  the  systems  prior  to  their  launch  and  questioned  four  areas: 

1 .  Inadequate  shielding  from  orbital  debris — this  was  a  basic  design  tradeoff  by  the 
Russians  to  keep  the  weight  down  and  was  designed  prior  to  the  ISS 
requirements."^^  With  the  exception  of  the  Zarya  module,  built  under  direct 
contract  to  the  US  government,  the  Russian  modules  were  too  heavy  to  add  any 
more  protective  panels  before  launch.  The  fix  would  be  to  later  install  panels  on 
orbit  if  needed. 

2.  Inability  of  Zarya  and  the  Service  Module  to  operate  after  losing  cabin  pressure. 
Much  of  the  critical  equipment  in  the  modules  required  air  for  cooling  electronics 
which  would  eventually  fail  in  a  vacuum.  This  risk  has  been  lessened  with  the 
addition  of  other  modules  with  redundant  capabilities. 

3.  Service  Module  Windows  not  certified — at  issue  is  whether  the  Russian  windows 
meet  the  requirements  of  surviving  a  leak  of  the  outside  pane  without  causing  a 
catastrophic  failure  or  permanent  leak.  The  window  design  planned  for  the 

“Russian  Compliance  with  Safety  Requirements,”  GAO/T-NSIAD-00-128,  16  March  2000 

The  ISS  requirement  was  to  have  no  more  than  a  2.4%  probability  of  penetration  over  a  15  year  life  on  orbit.  The 
assessment  was  that  the  modules  had  a  25%  probability.  With  the  addition  of  shielding  on  orbit,  the  probability 
drops  to  4%  for  the  remaining  life  of  the  station. 
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Service  Module  windows  did  not  meet  the  requirements  for  windows  used  on  the 
other  ISS  elements.  Several  areas  of  concern  included  insufficient  ultraviolet  and 
infrared  protection,  no  debris  pane  or  scratch  pane  to  protect  windows  from 
impacts  or  crew  induced  damage  and  no  way  to  safe  or  replace  a  window  should  a 
window  become  damaged  on-orbit.  The  windows  on  new  modules  are  supposed 
to  last  15  years,  but  the  Russian  design  requirement  was  only  five  years. 

4.  Noise  levels  on  the  Modules — the  ISS  requires  noise  levels  no  more  than  55 
decibels  over  a  24-hour  period,  but  the  noise  level  in  the  Russian  modules  are  in 
the  65-75  decibel  range.  This  was  an  issue  on  the  MIR,  and  several  astronauts 
suffered  temporary  or  permanent  hearing  loss.  Several  fixes  have  been 
implemented — more  insulation,  better  crew  hearing  protection,  and  replacement 
of  some  of  the  noisiest  equipment. 

2. 3. 7. 3  Aerospace  Safety  Advisory  Panel 

The  Aerospace  Safety  Advisory  Panel  (ASAP)  is  a  senior  advisory  committee  that  reports 
to  NASA  and  Congress.  The  Panel  was  established  by  Congress  after  the  Apollo  Command  and 
Service  Module  spacecraft  fire  in  January  1967."^^  This  panel  has  a  40+  year  history  of  providing 
support  to  NASA  and  all  of  its  programs.  It  is  normally  staffed  with  either  senior  or  retired 
experts  from  the  aerospace  field  to  include  previous  NASA  managers  and  astronauts. 

The  Panel's  statutory  duties,  as  prescribed  in  Section  6  of  the  NASA  Authorization  Act  of  1968, 
Public  Law  90-67,  42  U.S.C.  2477  are  as  follows: 

"The  Panel  shall  review  safety  studies  and  operations  plans  that  are  referred  to  it 
and  shall  make  reports  thereon,  shall  advise  the  Administrator  with  respect  to  the 
hazards  of  proposed  operations  and  with  respect  to  the  adequacy  of  proposed  or 
existing  safety  standards,  and  shall  perform  such  other  duties  as  the 
Administrator  may  request. " 

As  part  of  the  systems  engineering  process,  safety  plays  a  major  role  in  the  requirements, 
design,  development,  production  and  operation  of  the  systems.  In  the  case  of  NASA,  this  panel 
provides  oversight  to  all  of  these  areas,  but  does  so  in  a  limited  capacity.  The  Panel  does  not 
work  full  time  nor  is  it  staffed"^^  at  a  sufficient  level  to  allow  for  detailed  oversight  or  scrutiny. 
The  panel  also  has  limited  authority  other  than  recommendations  to  change  NASA  designs  or 
operations.  The  panel  provides  recommendations  to  the  NASA  Administrator,  develops  an 
annual  report,  and  reports  to  Congress. 

This  lack  of  authority  and  integration  into  the  operational  aspects  has  led  to  some  heated 
discussions  in  the  past.  Following  the  Columbia  accident  in  2003,  the  board  issued  a  report 
(and  gave  Congressional  testimony)  that  challenged  NASA  to  make  the  ASAP  more  independent 


NASA  Website:  http://www.hq.nasa.gov/office/oer/asap/history.html 

The  current  ASAP  has  eleven  members  to  include  the  director  and  an  administrative  officer. 

Testimony  to  the  Senate  Commerce,  Science,  and  Transportation  Committee  on  29  October  2003  by  Dr.  Arthur 
Zygielbaum. 
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and  to  give  it  an  operational  safety  role  in  launeh  deeisions  and  other  operation  aetivities.  The 
panel  stated  that  in  the  past,  NASA  program  managers  allowed  safety  margins  to  erode  in  the 
faee  of  sehedule  and  budget  pressures.  The  ASAP  reeommended  that  NASA’s  safety 
organization  be  plaeed  in  a  separate  ehain  of  eommand  that  reported  directly  to  the  Administrator 
and  thus  provided  a  veto  on  the  program  managers’  decisions  during  key  operations  (such  as 
launch  decisions).  In  a  report  issued  prior  to  the  Columbia  accident,  the  board  wrote: 

“It  is  traditional  in  NASA  for  project  and  program  managers  to  have  the  authority 
to  authorize  waivers  to  safety  requirements.  Safety  critical  waiver  authority 
should  reside  with  an  independent  safety  organization  using  independent  technical 
evaluation.  Moving  this  authority  would  increase  the  management  oversight  of 
safety-related  decisions  and  would  strongly  support  the  creation  of  a  well- 
respected  and  highly-skilled  safety  organization.” 

An  independent  technical,  quality  or  safety  oversight  board  is  not  a  new  concept.  In  most 
DoD  organizations  and  contracts,  groups  like  these  report  outside  of  the  program  managers  to 
guarantee  independence.  This  process  is  used  by  the  US  Navy  Sea  Systems  Command."^^  In  it, 
the  technical  authority  is  an  independent  expert  who  is  isolated  from  the  program  managers’ 
schedule  and  budget  pressures. 

The  ASAP  issues  a  yearly  report  that  often  contains  warnings  or  recommendations 
challenging  NASA  program  managers.  The  2002  report  was  a  prime  example;  the  report  listed  a 
string  of  incidents  or  potential  accidents  due  to  miscommunication  between  Russian  and 
American  engineers  that  indicated  a  dangerous  pattern  to  the  committee: 

■  Shortly  after  STS-1 13  docked  with  the  ISS,  there  was  a  loss  of  ISS  attitude  control  due  to 
a  lack  of  system  configuration. 

■  Lithium  thionyl  chloride  batteries  were  brought  on  board  over  the  objection  of  other  ISS 
partners. 

■  Russian  ground  controllers  sent  commands  to  fire  thrusters  before  US  ground  controllers 
had  disengaged  the  Control  Moment  Gyroscope  system. 

A  comment  was  made  by  a  former  ASAP  member^'^  that  there  might  be  communication  and 
cultural  issues  between  the  Russians  and  Americans  that  also  might  contribute  to  increased  risk 
of  accidents. 


NAVSEA  Instruction  5400. 97A,  Engineering  and  Technical  Authority  Policy,  dated  February  3,  2003 

Testimony  to  the  Senate  Commerce,  Science,  and  Transportation  Committee  on  29  October  2003  by  Dr.  Arthur 
Zygielbaum.  It  should  be  noted  that  this  testimony  was  triggered  by  the  resignation  of  the  entire  ASAP  the  month 
prior  (Sept  2003)  due  to  criticism  of  the  board  by  the  Columbia  Accident  Investigation  board. 


31 


3.0  FULL  SCALE  DEVELOPMENT 


3.1  Major  ISS  Modules 

3.1.1  Zarya  Control  Module 

The  Zarya  Module  (known  by  the  technical  term  Eunctional  Cargo  Block  and  the  Russian 
acronym  EGB)  was  the  first  component  launched  for  the  International  Space  Station.  This 
module  was  designed  to  provide  the  station's  initial  propulsion  and  power.  The  19,323-kilogram 
(42,600-pound)  pressurized  module  was  launched  on  a  Russian  Proton  rocket  in  November  1998 
(Eigure  10). 

As  part  of  the  business  arrangement  between  NASA  and  Russia,  the  United  States  funded 
this  component  of  the  station,  although  it  was  built  and  launched  by  Russia.  The  module  was 

built  by  the  Khrunichev  State  Research  and 
Production  Space  Center,  which  is  also  known 
as  KhSC,  in  Moscow  under  a  subcontract  to 
The  Boeing  Company  for  NASA. 

Construction  of  the  Zarya  Module 
began  at  KhSC  in  December  1994.  It  was 
shipped  to  the  Baikonur  Cosmodrome, 
Kazakhstan,  launch  site  to  begin  launch 
preparations  in  January  1998.  The  three-stage 
Proton  rocket  launched  the  module  into  a  220.4 
by  339.6  kilometer  (137  by  211  statute  miles) 
orbit. 

Only  two  weeks  after  Zarya  reached 
orbit.  Space  Shuttle  Endeavour  made  a 
rendezvous  and  attached  a  U.S. -built 
connecting  module  called  Node  1,  or  Unity. 
The  Zarya  Module  provided  orientation 
control,  communications,  and  electrical  power 
to  the  passive  Node  1  while  the  station  awaited 
launch  of  the  third  component,  a  Russian- 
provided  crew  living  quarters  and  early  station 
core  known  as  the  Zvezda  Service  Module.  The 
Service  Module  enhanced  or  replaced  many 
functions  of  Zarya.  The  Zarya  module  is  now  used  primarily  for  its  storage  capacity  and  external 
fuel  tanks. 

The  Zarya  Module  is  12.6  meters  (41.2  feet)  long  and  4.1  meters  (13.5  feet  wide)  at  its 
widest  point.  It  has  an  operational  lifetime  of  at  least  15  years.  Its  solar  arrays  and  six  nickel- 
cadmium  batteries  can  provide  an  average  of  3  kilowatts  of  electrical  power.  Its  nadir  docking 
port  accommodates  either  a  Russian  Soyuz  piloted  spacecraft  or  an  unpiloted  Progress  resupply 
spacecraft.  As  the  station  grew,  it  became  necessary  to  send  an  extension  module  (the  Mini 
Research  Module  1,  or  MRMl)  to  create  a  tunnel  from  this  nadir  port  further  towards  the  nadir, 
to  provide  docking  clearance  and  additional  ports  for  visiting  vehicles.  Each  of  the  two  solar 


Figure  10.  Russian  Zarya  Module 
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arrays  is  10.7  meters  (35  feet)  long  and  3.4  meters  (11  feet)  wide.  The  module's  16  fuel  tanks 
combined  can  hold  more  than  5.4  metric  tons  (6  tons)  of  propellant.  The  attitude  control  system 
for  the  module  included  24  large  steering  jets  and  12  small  steering  jets.  Its  two  300  kgf  engines 
were  used  for  reboosting  the  spacecraft  and  making  major  orbital  changes  before  Zvezda  arrived. 
All  of  these  engines  were  de-activated 
several  months  after  the  Service  Module 
arrived,  leaving  the  FGB  to  serve  as  a 
propellant  storage  and  feed  system  to  the 
Service  Module  and  the  visiting  vehicles. 

3.1.2  Unity  Node 

The  Unity  module  (Node  1)  was  the 
first  major  U.S. -built  component  of  the 
station  and  was  delivered  during  STS-88 
on  Space  Shuttle  Endeavour  in  December 
1998.  It  includes  the  Pressurized  Mating 
Adapter  1  pre-fitted  to  its  aft  port. 

Assembly  required  crews  to  conduct  three 
space  walks  to  attach  the  Pressurized 
Mating  Adapter  1  to  the  Zarya  Control 
Module,  and  to  outfit  exterior  gear  such  as 
handrails,  cables,  radio  equipment,  etc. 

In  addition  to  its  connection  to  Zarya,  Unity  serves  as  a  passageway  to  the  U.S. 
Laboratory  Module  (attached  later)  an  airlock,  and  other  future  growth  modules.  It  has  six 
hatches  that  serve  as  docking  ports  for  the  other  modules.  It  is  5.5  meters  (18  feet)  long,  4.6 
meters  (15  feet)  in  diameter  and  fabricated  of  aluminum.  The  Unity  Node  contains  more  than 
50,000  mechanical  items,  216  lines  to  carry  fluids  and  gases,  and  121  internal  and  external 
electrical  cables  using  9.7  kilometers  (6  miles)  of  wire. 

Two  additional  nodes  (Node  2  Harmony  and  Node  3  Tranquility)  were  built  for  NASA 
by  ESA  and  launched  in  October,  2007  and  Eebruary,  2010  respectively.  Harmony  serves  as  the 
connection  to  the  ESA  Columbus  and  JAXA  Kibo  modules,  discussed  later,  as  well  as  the 
docking  port  for  the  Space  Shuttle  and  later  U.S.  cargo  and  crew  vehicles.  Tranquility  serves  as 
the  base  for  the  cupola,  also  discussed  later. 

3.1.3  Zvezda  Service  Module 

The  history  of  the  Zvezda  module  goes  back  to  the  late  stages  of  the  Cold  War  when  it 
was  originally  intended  as  a  cornerstone  of  the  Russian  Mir-2  space  station.  The  service  module 
closely  resembled  the  core  module  of  the  Mir  space  station  and  its  design  lineage  traces  back  to 
the  Salyut  and  Almaz  space  station  programs  (see  Figure  12).  This  was  the  first  full  Russian 
contribution  to  the  ISS  and  was  fully  funded  by  the  Russians.  The  Zvezda  module  was  initially 
planned  to  launch  in  1999.  Given  Russian  delays,  NASA  embarked  on  development  of  a  back-up 
module  with  the  intent  of  securing  the  critical  path  in  the  assembly  sequence. 

Zvezda  was  launched  on  July  12,  2000  from  the  Baikonur  Cosmodrome  in  Kazakhstan.. It 
served  as  the  early  station  living  quarters  and  as  the  main  docking  port  for  the  Russian  Progress 


Figure  11.  US  Unity  Module 


33 


cargo  resupply  vehicles.  It  also  provided  early  propulsive  attitude  control  and  re -boost 
capabilities  for  the  station.  Zvezda's  living  accommodation^'  provided  two  personal  sleeping 
quarters,  a  toilet  and  hygiene  unit,  a  galley  with  a  refrigerator-freezer  and  a  table  for  securing 
meals  while  eating.  Its  14  windows  offered  direct  viewing  of  doeking  activities,  the  Earth  and 
other  Station  elements.  Exercise  equipment  included  a  treadmill  and  a  fixed  bicycle.  Cosmonauts 
wearing  Orlan-M  (and  later,  the  Orlan  MK)  spacesuits  used  the  Transfer  Compartment  as  an 
airlock.  Zvezda  also  provided  data,  voice  and  TV  links  with  mission  control  centers  in  Moscow 
and  Houston. 


Figure  12.  Zvezda  Module  with 


3,1,4  Destiny  Laboratory  Module 

The  Boeing-built,  Destiny  Laboratory  Module  arrived  at  Kennedy  Space  Center,  Ela.  in 
November  1998  to  begin  final  preparations  for  its  launch  on  Eeb.  7,  2001,  aboard  Space  Shuttle 
mission  STS-98,  Station  assembly  flight  5A.  As  the  first  major  laboratory.  Destiny  was  the 
centerpieee  of  the  US  portion  of  International  Space  Station,  where  science  experiments  were 
performed  in  the  near-zero  gravity  of  space.  The  aluminum  module  consisted  of  three  cylindrical 
sections  and  two  end  cones  with  hatches  that  were  mated  to  the  Unity  module  at  one  end,  and 


http://www.russianspaceweb.com/iss_sm.html 

The  windows  in  this  module  represented  a  difference  in  Russian  design  philosophy  that  placed  importance  on 
windows  (for  reconnaissance,  research  and  crew  considerations)  vice  the  western  designs  that  minimized  the  number 
of  windows  for  safety  reasons  (a  later  US  module  would  only  contain  a  single,  large  window). 

Note,  while  the  ISS  had  redundant  airlocks  early  in  assembly,  the  Russian  airlock  would  only  accommodate  the 
Russian  spacesuits  and  not  the  American  suits. 
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would  have  the  PMA-2  doeking  adaptor  attached  at  the  other  on  a  later  mission  (See  Figures  13 
and  14). 

When  it  arrived  at  the  ISS,  Destiny  had  five  racks  housing  electrical  and  life-support 
systems.  Subsequent  shuttle  missions  have  delivered  more  racks  and  experiment  facilities, 
including  the  Microgravity  Science  Glove  box,  the  Human  Research  Facility  and  five  racks  to 
hold  various  science  experiments.  Eventually,  Destiny  would  hold  13  payload  racks  with 
experiments  in  human  life  science,  materials  research.  Earth  observations  and  commercial 
applications,  plus  eleven  systems  and  storage  racks. 


Figure  1 3.  US  Destiny  Laboratory  Module 


A  50.9  centimeter  diameter  window  was  located  on 
the  nadir  side  of  the  central  module  segment  and  is  the  largest 
window  ever  to  be  incorporated  in  a  space  station.  Destiny's 
window  (Figure  14),  which  takes  up  the  space  of  one  rack,  is 
of  optical  quality  that  enables  scientific  quality  photos, 
measurements  and  video.  The  window  is  protected  by  both 
internal  and  external  covers  to  avoid  degradation  of  the  glass. 
The  Window  Observational  Research  Facility  rack  was  later 
deployed  to  house  scientific  and  observational  equipment  for 
use  on  the  window. 

The  aluminum  module  is  28  feet  long  and  14  feet  in 
diameter.  The  lab  consisted  of  three  cylindrical  sections  and 
two  end  cones  with  hatches  that  were  mated  to  other  station 
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Figure  1 4.  US  Destiny  Module 
High  Grade  Optical  Window 


components.  An  exterior  waffle  pattern  strengthens  the  hull  of  the  lab.  The  exterior  is  covered 
by  a  debris  shield  blanket  made  of  Kevlar  similar  to  that  used  in  bulletproof  vests.  A  thin 
aluminum  “sandwich”  debris  shield  was  placed  over  the  blanket  for  additional  protection.  This 
module  served  as  the  primary  living  quarters  for  the  non-Russian  crewmembers  during  most  of 
the  assembly  of  the  ISS. 


3.1.5  Canadian  Space  Robotics  System 

The  Canadian  space  robotics  system, 
formally  called  the  Mobile  Servicing  System  or 
MSS,  is  an  essential  component  of  the  ISS.^"^  The 
MSS  provides  astronauts  the  ability  to  move 
equipment  and  supplies  around  the  exterior  of  the 
ISS  (Figure  15).  It  supported  astronauts  when 
they  were  working  in  space  and  could  be  used  to 
release  and  capture  satellites.  The  system  has 
three  parts: 

•  Canadarm  2,  the  Space  Station  Remote 
Manipulator  System  (SSRMS)  - 
delivered  to  the  ISS  in  April  2001 

•  the  Mobile  Remote  Servicer  Base 
System  (MRSBS)  -  a  work  platform 
which  moves  on  rails  along  the  length  of  the  space  station  -  delivered  to  the  ISS  in 
2002 

•  the  Special  Purpose  Dexterous  Manipulator  (DEXTRE)  -  the  space  robotics  "Canada 
Hand,"  which  has  two  arms  of  its  own  -  delivered  in  2007. 

The  contribution  of  this  technology,  including  Canadarm  2,  helps  CSA  pay  for  its  share  of  ISS 
operating  costs.  It  means  CSA  has  access  rights  to  the  space  station  lab  facilities  for  experiments. 
It  also  means  that  CSA  may  send  an  astronaut  to  the  ISS  approximately  every  three  years. 

3.1.6  Quest  Joint  Airlock 

The  Joint  Airlock  (also  known  as  "Quest")  (Eigure  16)  was  built  by  the  U.S.  and  provided 
the  capability  for  ISS-based  Extravehicular  Activity  (EVA)  using  either  a  U.S.  Extravehicular 
Mobility  Unit  (EMU)  or  Russian  Orlan  EVA  suits.  Before  the  launch  of  this  airlock,  EVAs  were 


Figure  15.  Canadian  Space  Robotics 
System 


“Canadarm  2,”By  Susan  Monroe,  Canada  Online  (http://canadaonline.about.com) 
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performed  from  either  the  U.S.  Spaee  Shuttle  (while  doeked)  or  from  the  Transfer  Chamber  on 
the  Serviee  Module.  Due  to  a  variety  of  system  and  design  differenees,  only  U.S.  spaee  suits 
could  be  used  from  the  Shuttle  and  only  Russian  suits  could  be  used  from  the  Service  Module. 
The  Joint  Airlock  alleviates  this  problem  by  allowing  either  (or  both)  spacesuit  systems  to  be 
used.  In  the  past,  if  the  Shuttle  was  not  docked,  then  the  Russian  space  suits  had  to  be  used 
through  the  Russian  docking  port  if  an  EVA  was  required.  The  variation  in  airlocks  and 
spacesuits  available  on  the  ISS  provides  an  important  level  of  dissimilar  redundancy  for  the  EVA 
function. 

The  Joint  Airlock  was  launched  on  ISS-7A  /  STS-104  in  July  2001  and  was  attached  to 
the  starboard  docking  port  of  Node  1.  The  Joint  Airlock  is  20  feet  long,  13  feet  in  diameter,  and 
weighs  6.5  tons.  The  Joint  Airlock  was  built  by  Boeing  at  Marshall  Space  Elight  Center.  The 
Joint  Airlock  was  launched  with  the  High  Pressure  Gas  Assembly.  The  High  Pressure  Gas 
Assembly  was  mounted  on  the  external  surface  of  the  Joint  Airlock  and  supports  EVA  operations 
with  breathing  gases  and  augments  the  Service  Module's  gas  resupply  system. 

The  Joint  Airlock  has  two  main  components:  a  crew  airlock  from  which  astronauts  and 
cosmonauts  exit  the  ISS  and  an  equipment  airlock  designed  for  storing  EVA  gear  and  for  so- 
called  overnight  "campouts"  wherein  nitrogen  is  purged  from  astronaut's  bodies  overnight  as 
pressure  is  dropped  in  preparation  for  spacewalks  the  following  day.  This  procedure  prevents 
the  bends  as  the  astronauts  are  re-pressurized  after  their  EVA.  Without  the  ‘campout’  procedure, 
the  cabin  pressure  in  the  entire  ISS  would  have  to  be  lowered  prior  to  each  EVA.  The  crew 
airlock  was  derived  from  the  Space  Shuttle's  external  airlock.  It  is  equipped  with  lighting, 
external  handrails,  and  an  Umbilical  Interface  Assembly  (UIA).  The  UIA  is  located  on  one  wall 
of  the  crew  airlock  and  provides  a  water  supply  line,  a  wastewater  return  line,  and  an  oxygen 
supply  line.  The  UIA  also  provides  communication  gear  and  spacesuit  power  interfaces  and  can 
support  two  crew  in  spacesuits  simultaneously.  These  can  be  either  two  American 
Extravehicular  Mobility  Unit  (EMU)  spacesuits,  two  Russian  Orlan  spacesuits,  or  one  of  each 
design. 


Before  the  crew  airlock's  hatch  is  opened  to  space,  the  crew  airlock  is  depressurized  to  3 
pounds  per  square  inch  (psi)  from  the  ISS  pressure  of  14.7  (psi)  and  then  down  to  zero  psi.  To 
conduct  this  depressurization,  a  Russian-built  compressor  temporarily  moves  most  of  the  air 
within  the  airlock  to  the  main  pressurized  volume  of  the  ISS.  At  the  end  of  the  EVA,  the  airlock 
is  re-pressurized  from  this  cabin  air.  By  conserving  the  air,  even  at  only  1 .2  kilograms  per  cubic 
meter,  several  tons  of  logistics  are  saved  over  the  life  of  the  program.  The  Quest  airlock  is  the 
only  airlock  in  space  history  to  conserve  its  air. 


The  atmosphere  inside  spacesuits  is  pure  oxygen  at  4.3  psi.  Current  spacesuit  design 
requires  these  lower  pressures  in  order  for  the  suits  to  be  flexible  enough  to  work  within.  At 
higher  pressures  the  suits  stiffen  and  are  hard  to  work  in  for  prolonged  periods  of  time. 
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Figure  1 7.  Russian  Pirs  Docking 

The  Equipment  Airloek  has  stations  that  assist  Compartment 

astronauts  and  cosmonauts  as  they  move  into  and  out  of  their  spacesuits  during  periodic 
maintenance.  The  Equipment  airlock  has  two  racks,  one  for  avionics,  and  the  other  for  cabin  air. 
Batteries,  power  tools  and  other  supplies  are  also  stored  in  the  Equipment  Airlock. 

3,1,7  Russian  Pirs  Docking  Compartment 

The  3,580  kilogram  Pirs  Docking  Compartment  is  attached  to  the  nadir  (bottom.  Earth¬ 
facing)  port  of  the  Zvezda  service  module  (Eigure  17).  It  was  docked  to  the  ISS  on  September 
16,  2001,  and  was  configured  during  three  spacewalks  by  the  Expedition  3  crew.^^ 


NASA  official  site,  PIRS  mission  data, 
http://www.nasa.gov/mission_pages/station/structure/iss_assembly_4r.html 
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Pirs  was  launched  Sept.  14,  2001,  as  ISS  Assembly  Mission  4R,  on  a  Russian  Soyuz 
roeket,  using  a  modified  Progress  spaeeeraft  as  an  upper  stage.  The  Doeking  Compartment  has 
two  primary  funetions.  It  serves  as  a  doeking  port  for  the  doeking  of  Soyuz  transport  and 
Progress  eargo  vehieles  to  the  ISS,  and  as  an  airloek  for  spaeewalks  by  two  ISS  erewmembers 
using  Russian  Orlan-M  spaeesuits. 

In  addition,  the  Doeking  Compartment  ean  transport  propellants  from  the  tanks  of  a 
doeked  Progress  resupply  vehiele  to  either  the  Zvezda  Serviee  Module  Integrated  Propulsion 
System  or  the  Zarya  Funetional  Cargo  Bloek.  It  ean  also  transfer  propellant  from  Zvezda  and/or 
from  Zarya  to  the  propulsion  system  of  Progress.  The  doeking  eompartmenfs  planned  lifetime  as 
part  of  the  station  was  five  years,  but  signifieant  delay  of  its  permanent  replaeement:  the 
Multipurpose  Laboratory  Module  (MLM:  built  from  the  flight  spare  of  the  original  Russian  FOB 
module;  see  seetion  3.1.11)  meant  that  it  had  to  stay  for  several  additional  years.  A  nearly- 
identieal  Doeking  Compartment,  dubbed  the  Multipurpose  Researeh  Module  2  (MRM2),  joined 
the  ISS  at  the  Serviee  Module  Zenith  port  in  late  2009.  MRM2  replaeed  a  eaneelled  prior 
eoneept  for  a  Russian  solar  array  tower  ealled  the  Seienee  Power  Platform  (SPP).  MRM2 
instead  ereated  a  fourth  doeking  port  for  Soyuz  and  Progress  vehieles,  greatly  simplifying  the 
traffie  planning  at  the  ISS. 

3,1,8  Columbus  Laboratory 

The  European  Columbus  Laboratory  (Figure  18)  was  launehed  on  the  Spaee  Shuttle  on  7 
February  2008  and  sueeessfully  attaehed  to  the  ISS  on  11  February.  Columbus  represents  the 
European  Spaee  Ageney’s  largest  eontribution  to  the  ISS  and  is  a  eritieal  pieee  to  bring  the  ISS 
researeh  eapability  to  fruition. 


“ISS:  Columbus,”  A.  Thirkettle,  B.  Patti,  P.  Mitschdoerer,  R.  Kledzik,  E.  Gargioli,  and  D.  Brondolo.  European 
Space  Agency. 
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Figure  18.  ESA  Columbus  Research  Module 

The  research  laboratory  accommodates  ten  science  racks,  five  of  them  for  European 
Space  Agency  use,  the  other  five  for  NASA  use.  It  is  used  primarily  for  research  and 
experimentation  in  microgravity  conditions  for: 

■  Microgravity  Sciences,  to  study  processes  that  are  obscured  by  gravity  on  Earth,  and  to  test 
physical  theories  at  levels  of  accuracy  that  are  impossible  on  Earth  —  again,  due  to  the 
planet's  gravity. 

■  Eluid  Physics,  to  learn  the  behavior  and  properties  of  fluids  in  microgravity  and  develop 
techniques  to  improve  oil  spill  recovery  techniques,  tracking  of  ground  water  contaminants, 
optical  lens  fabrication,  and  many  other  processes. 

■  Eife  Sciences,  to  learn  how  flora  and  fauna  growth  and  disease  occur  in  microgravity  and  to 
convert  what  is  learned  into  strategies  for  dealing  with  disease  and  disability  on  Earth. 

The  Columbus  module  also  provides  four  external  payload  attach  sites. 

3,1,9  Kibo  Japanese  Experimental  Laboratory 

The  Japanese  Experiment  Module  (JEM),  called  Kibo,  was  Japan's  first  human  space 
facility  and  the  largest  module  system  on  the  ISS  when  completed  in  mid  2009  (Eigure  19). 
Experiments  in  Kibo  focus  on  space  medicine,  biology.  Earth  observations,  material  production, 
biotechnology  and  communications  research.  Kibo  experiments  and  systems  are  operated  from 
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the  Mission  Control  Room  at  the  Space  Station  Integration  and  Promotion  Center  (SSIPC),  at 
Tsukuba  Space  Center  in  Ibaraki  Prefecture,  Japan,  just  north  of  Tokyo. 

Kibo  consists  of  six  components:  two  research  facilities  —  the  Pressurized  Module  and 
Exposed  Facility;  a  Logistics  Module  attached  to  each  of  them;  a  Remote  Manipulator  System; 
and  an  Inter-Orbit  Communication  System  unit.  Kibo  also  has  a  scientific  airlock  through  which 
experiments  are  transferred  and  exposed  to  the  external  environment  of  space.  The  various 
components  of  Kibo  were  assembled  in  space  over  the  course  of  three  Space  Shuttle  missions. 

1 .  Pressurized  Module:  The  Pressurized  Module  (PM)  provides  a  shirt-sleeve  environment 
in  which  astronauts  conduct  microgravity  experiments.  There  are  a  total  of  23  racks, 
including  10  experiment  racks,  inside  the  PM  providing  a  power  supply, 
communications,  air  conditioning,  hardware  cooling,  water  control  and  experiment 
support  functions.  As  in  Columbus,  of  the  ten  experiment  rack  locations  in  Kibo,  5  are 
allocated  to  JAXA  and  5  to  NASA.  The  PM  is  1 1.2  meters  (36.7  feet)  long  and  4.4 
meters  (14.4  feet)  in  diameter,  about  the  size  of  a  large  tour  bus.  This  module  was  so 
large  (at  15  tons)  that  it  was  launched  empty  and  most  racks  and  other  equipment  were 
added  separately. 

2.  Exposed  Facility:  The  Exposed  Facility  (EE)  is  located  outside  of  the  Pressurized 
Module  and  is  continuously  exposed  to  the  space  environment.  Astronauts  exchange 
experiment  payloads  or  hardware  from  the  Pressurized  Module  through  the  unique 
scientific  airlock  using  the  Kibo  Remote  Manipulator  System.  Items  positioned  on  the 
exterior  platform  focus  on  Earth  observation  as  well  as  communication,  scientific, 
engineering  and  materials  science  experiments.  The  EE  is  a  platform  that  can  hold  up  to 
10  experiment  payloads  at  a  time  and  measures  5.6  meters  (18.4  feet)  wide,  5  meters 
(16.4  feet)  high  and  4  meters  (13.1  feet)  long. 
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Figure  19.  Japanese  Kibo  Experimental  Module  and  Facilities 


3.  Experiment  Logistics  Modules  (ELM)  (Pressurized  and  Exposed  Sections):  The 
Experiment  Logistics  Modules,  or  ELMs,  serve  as  on-orbit  storage  areas  that  house 
materials  for  experiments,  maintenance  tools  and  supplies.  The  Pressurized  Module  and 
the  Exposed  Eacility  each  have  an  ELM. 

a.  Pressurized  Section;  The  Experiment  Logistics  Module  -  Pressurized  Section,  or 
ELM-PS,  is  a  short  cylinder  attached  to  the  top  of  the  Pressurized  Module  that  can 
hold  eight  experiment  racks.  It  measures  4.4  meters  (14.4  feet)  in  diameter  and 
3.9  meters  (12.8  feet)  long. 

b.  Exposed  Section;  The  Experiment  Logistics  Module  -  Exposed  Section,  or  ELM- 
ES,  is  a  pallet  that  can  hold  three  experiment  payloads.  It  measures  4.9  meters 
(16.1  feet)  wide,  2.2  meters  (7.2  feet)  high  and  4.2  meters  (13.8  feet)  long. 

4.  Remote  Manipulator  System;  The  Remote  Manipulator  System,  or  RMS,  consists  of  two 
robotic  arms  that  support  operations  on  the  outside  of  Kibo.  The  Main  Arm  can  handle  up 
to  6.4  metric  tons  (14,000  pounds)  of  hardware  and  the  Small  Line  Arm,  when  attached  to 
the  Main  Arm,  handles  more  delicate  operations.  Each  arm  has  six  joints  that  mimic  the 
movements  of  a  human  arm.  Astronauts  operate  the  robot  arms  from  a  remote  computer 
console  inside  the  Pressurized  Module  and  watch  external  images  from  a  camera  attached 
to  the  Main  Arm  on  a  television  monitor  at  the  RMS  console.  The  arms  are  specifically 
used  to  exchange  experiment  payloads  or  hardware  located  on  the  Exposed  Facility  and 
Experiment  Logistics  Module  -  Exposed  Section  and  from  inside  the  Pressurized  Module 
through  a  scientific  airlock,  support  maintenance  tasks  of  Kibo  and  handle  orbital 
replacement  units.  The  Main  Arm  measures  9.9  meters  (32.5  feet)  long,  and  the  Small 
Fine  Arm  measures  1.9  meters  (6.2  feet). 
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3,1,10  Cupola 


The  Cupola  (Figure  20)  is  a  European  Space  Agency  (ESA)-built  observatory  module  of 
the  International  Space  Station  (ISS).^^  Its  purpose  is  to  provide  ISS  crew  members  with  a  direct 
view  of  robotic  operations  and  docked  spacecraft,  as  well  as  an  observation  point  for  watching 
the  Earth.  The  Cupola  project  was  started  by  NASA  and  Boeing,  but  was  cancelled  as  a  result  of 
cost  cuts  early  in  the  ISS  design  period.  After  a  barter  agreement  between  NASA  and  ESA, 
development  of  the  Cupola  was  later  taken  over  by  ESA  in  1998.  Designed  and  built  by  the 
Italian  contractor  Alenia,  it  is  approximately  2  meters  in  diameter  and  1 .5  meters  tall.  It  has  six 
side  windows  and  a  top  window,  all  of  which  are  equipped  with  shutters  to  protect  them  from 
damage  by  micrometeoroids  and  orbital  debris.  It  features  a  thermal  control  system,  audio,  video 
and  MIL-STD-1553  bus  interfaces,  as  well  as  the  connections  needed  for  installing  in  it  one  of 
the  two  identical  robotic  workstations  that  control  the  Canadarm2.  The  Cupola  was  launched 
aboard  STS-130,  in  Erbruary,  2010  along  with  node  3.. 


Figure  20.  Cupola  Observation  Modules 

Alenia  Spazio  Cupola  Project  Manager,  Doriana  Buffa,  says  the  Cupola,  with  its  seven 
windows,  is  very  unlike  any  of  the  other  modules  on  the  Station.  Its  most  important  contribution 
is  for  making  long  duration  space  flights  easier  on  the  crew: 

“The  large  viewing  windows  will  provide  the  astronauts  with  a  view  of  the  Earth 
quite  unlike  any  other.  Eor  long-stay  crews  this  will  provide  them  with  an 
important  psychological  boost-an  umbilical  cord  connecting  the  crew  on  the 
Station  to  Mother  Earth.” 

While  not  discussed  in  most  systems  engineering  texts,  the  ability  of  the  crew  to  function 
long  term  under  often  stressful  situations  must  be  part  of  the  system’s  design  and  part  of  the 
system  engineering  process.  This  specialty  is  part  of  human  factors  engineering,  a  recognized 
area  of  expertise  at  NASA’s  Johnson  Space  Center. 

3,1,11  Russian  Multi-Purpose  Laboratory  Module 


European  Space  Agency  News,  http://www.esa.int/esaCP/SEMHALOXDYD_Life_0.html 
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The  Russian  Multi-purpose  Laboratory  Module  (MLM)  (Figure  21)  has  a  long  history  of 
starts  and  stops.  It  was  originally  started  as  a  backup  to  the  Zarya  module  (as  the  FGB2)  and  was 
almost  70%  complete  when  construction  was  halted.  Then  it  was  to  be  modified  and  used  as  the 
universal  docking  module,  which  was  later  cancelled.  The  Russians  always  had  plans  for  a 
research  module  (or  two)  and  in  2005  it  was  decided  to  convert  the  existing  FGB2  into  the 
MLM.  During  final  design  discussions,  an  agreement  was  made  with  ESA  to  have  the  European 
Robotic  Arm  mated  on  its  surface  for  a  later  deployment  in  space.  The  production  and  assembly 
suffered  several  delays  and  its  launch  on  a  Proton  boost  vehicle  slipped  to  2009. 


The  MEM  is  capable  of  supporting  commercial 
projects  to  a  moderate  degree,  limited  by  power  and 
thermal  constraints  at  its  shaded  nadir  position.  This 
commercial  payload  concept  allowed  the  Russians  to 
outsource  off-budget  funding  including  investments  to 
be  used  to  complete  and  commission  the  module.  Eor 
the  Russians,  more  so  than  other  IP  partners,  the 
ability  to  generate  revenue  has  been  critical  to  their 

c  o 

continued  participation  in  the  ISS. 

hollowing  are  the  requirements  set  for  the  EGB  2- 
based  MEM  as  derived  from  the  input  data: 

■  Provide  a  port  for  Soyuz  and  Progress 
vehicles  and  their  modifications  as  well  as 
for  research  modules  to  be  able  to  dock  in 
either  automatic  or  manual  mode. 

■  Support  propellant  transfer  from  Progress 
vehicles  into  the  SM  and  EGB  tanks. 

■  Support  the  ISS  roll  control  using  its  own  jets. 

■  Provide  room  to  accommodate  European  Robotic  Arm,  provide  footprints  for  external 
experiments  and  for  a  cargo  pallet,  install  probes  for  stowage  and  maintenance  of 
EVA  payloads. 


Figure  21.  Russian  Multi-Purpose 
Laboratory  Module 


Gunter’s  Space  Page, 

http  ://space. skyrocket. de/index_frame.htm?http://www. skyrocket.de/space/doc_sdat/mlm.htm 
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3,1,12  Multi-Purpose  Logistics  Module 

The  three  Multi-Purpose  Logistics  Modules  (MPLMs)  (Figure  22),  which  were  built  by 
Alenia-Spazio  for  the  Italian  Space  Agency,  are  pressurized  modules  that  serve  as  the 
International  Space  Station's  "moving  vans,"  carrying  equipment,  experiments  and  supplies  to 
and  from  the  ISS  aboard  the  Space  Shuttle. 

The  unpiloted,  reusable  MPLM  functions  as  both  a  cargo  carrier  and  a  temporary  Space 
Station  module.  Mounted  in  the  Space  Shuttle's  cargo  bay  for  launch  and  landing,  it  is  berthed  to 
the  ISS  using  the  Shuttle's  robotic  arm  after  the  Shuttle  has  docked.  While  berthed  to  the  ISS, 
racks  and  equipment  are  unloaded  from  the  module  and  then  old  racks  and  equipment  may  be 
reloaded  to  be  taken  back  to  Earth. 

The  Logistics  Module  is  then  detached  from  the  Station  and  positioned  back  into  the 
Shuttle's  cargo  bay  for  the  trip  home.  When  in  the  cargo  bay,  the  module  is  independent  of  the 
Shuttle  cabin,  and  there  is  no  passageway  for  Shuttle  crewmembers  to  travel  from  the  Shuttle 
cabin  to  the  module. 

In  order  to  function  as  an  attached  Station  module  as  well  as  a  cargo  transport,  the 
MPLM  also  includes  components  that  provide  air  circulation,  fire  detection  and  suppression, 
electrical  distribution  and  computer  functions.  Ultimately,  one  of  the  MPLMs  is  to  be  re-named 
the  Permanent  Logistics  Module  (PLM)  and  will  remain  on  the  ISS.  Significant  upgrades  to  its 
debris  protection  are  required  for  this  long-duration  stay,  unprotected  by  the  orbiter  payload  bay. 


Figure  22.  Interior  of  Italian  Multi-Purpose  Logistics  Modules 


Official  NASA  information  site:  http://www.nasa.gov/mission_pages/station/structure/elements/mplm.html 
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Although  built  in  Italy,  the  logistics  modules  are  U.S  elements,  and  were  provided  in 
exchange  for  Italian  access  to  U.S.  research  time  on  the  Station. 

Construction  of  the  Leonardo  module  began  in  April  1996  at  the  Alenia  Aerospazio 
factory  in  Turin,  Italy.  Leonardo  was  delivered  to  the  Kennedy  Space  Center  from  Italy  in 
August  1998  by  a  special  Beluga  cargo  aircraft.  Raffaello  arrived  at  Kennedy  in  August  1999. 
The  third  module,  named  Donatello,  was  delivered  to  Kennedy  on  February  1,  2001. 

Each  cylindrical  module  is  approximately  21  feet  long  and  15  feet  in  diameter,  weighing 
almost  4.5  tons.  Each  module  can  carry  up  to  10  tons  of  cargo  packed  into  16  standard  Space 
Station  equipment  racks.  Of  the  16  racks  the  module  can  carry,  five  can  be  furnished  with 
power,  data  and  fluid  to  support  a  refrigerator  freezer. 

One  of  the  MPEM’s  is  being  modified  to  remain  on  station  as  a  storage  module  when  the 
Space  Shuttle  retires. 

3,2  Launch  Services 

A  major  decision  and  assumption  was 
that  the  required  launch  services  would,  at  least 
initially,  all  come  from  existing  vehicles.  This 
meant  the  ISS  was  designed  with  the  Shuttle  and 
Russian  launch  vehicles  as  critical  components 
for  the  long-term  success  of  the  ISS.  This  total 
dependency  on  these  two  sources  of  lift  has 
become  a  critical  issue  (see  3.4.5)  with  the 
announcement  by  the  United  States  to  retire  the 
Shuttle  by  2010  without  a  direct  replacement. 


3,2,1  Shuttle 

The  construction  of  the  ISS  was  designed  to  rely  upon  the  Space  Shuttle  to  provide  heavy 
lift  and  crew  transportation — indeed,  this  was  one  of  the  main  design  criteria  for  the  Space 
Shuttle.  In  addition,  the  Space  Shuttle  provided  regular  “house  calls”  of  large  teams  of  short¬ 
term,  specially-skilled  assembly  astronauts  for  each  key  phase  of  assembly.  While  the  Russians 
used  their  heavy  lift  Proton  rockets,  NASA  had  no  plans  to  use  expendable  launch  vehicles  for 
its  (or  its  partners’)  large  ISS  modules.  All  NASA  and  IP  hardware  were  designed  to  interface 
with  the  Space  Shuttle  payload  bay  as  well  as  to  adhere  to  the  launch  requirements  (loads  etc.) 
that  are  more  stringent  than  other  vehicles  because  of  its  human  rating. 

The  Space  Shuttle  allowed  NASA  and  its  IPs  to  send  up  short-term  “construction”  crews 
to  the  ISS  to  assemble  modules  and  trusses  with  the  full  support  and  flexibility  of  the  Space 
Shuttle.  The  Space  Shuttle  serves  as  a  stand-alone  research  and  assembly  support  vehicle  with 
significant  up-load  capability  (Eigure  23).  With  the  advent  of  the  Shuttle  retirement,  a  key 
function  will  be  retired  without  replacement:  capability  to  return  large  (anything  larger  than  can 
fit  in  the  Soyuz)  payloads  to  Earth  -  which  also  requires  changes  to  the  ISS  logistics  and 
maintenance  strategy.  Instead  of  rotating  failed  Orbital  Replacement  Units  (ORUs)  with  spares 
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stored  on  the  ground,  equipment  will  need  to  be  repaired  on-orbit  or  spares  will  need  to  be  pre¬ 
positioned  on-orbit. 

3.2.2  New  NASA  capability 

In  2004,  NASA  was  direeted  by  the  Administration^®  to  develop  not  only  a  replacement 
for  the  Space  Shuttle,  but  a  family  of  vehicles  that  would  extend  space  exploration  to  the  moon 
and  beyond.  The  replacement  for  the  Space  Shuttle  became  the  Ares  I  rocket  and  Orion  Crew 
Exploration  Vehicle,  part  of  the  larger  NASA  Constellation  Program.  These  were  to  provide 
transportation  for  the  crew,  but  no  significant  ability  to  upload  or  download  ISS  payloads.  With 
the  Space  Shuttle  able  to  finish  supporting  the  ISS  as  currently  planned  (through  completion  of 
assembly),  this  was  not  to  be  an  issue.  In  January  2010  the  Obama  administration  ordered  a 
restructuring  of  Constellation  activities,  and  a  re-definition  of  the  Orion  effort  to  create  a  US- 
built  lifeboat  capability  for  the  ISS,  with  an  option  to  evolve  the  spacecraft  for  later  missions. 
The  ARES  1  booster  was  canceled,  and  the  larger  ARES-5  booster  is  to  be  redefined.  These 
actions  leave  the  final  configuration  and  capabilities  of  the  Orion-derived  capsule  to  be  defined 
at  the  time  of  this  case  study’s  publication.  Any  transport  capability  of  the  future  will  have 
limited  ability  to  bring  up  spares.  Some  orbital  replacement  units  are  so  large  that  only  the  Space 
Shuttle  can  deliver  them,  or  replace  key  components  (like  solar  arrays)  if  they  fail  earlier  than 
planned.  Eurthermore,  the  lack  of  Space  Shuttle  payload  capability  may  also  impact  the 
operational  life  and  any  recertification  activities. 

3.2.3  Russian  Vehicles 

The  Russians  have  played  a  critical  role  in  providing  launch  services  for  the  astronauts 
and  for  recurring  supply  missions  to  the  ISS.  The  early  plans  were  that  the  Shuttle  would  supply 
all  of  the  heavy  lifting  of  key  ISS  components,  supplies  and  astronauts.  While  the  Shuttle  did 
eventually  lift  the  major  ISS  elements  into  orbit,  the  frequency  of  flights  was  never  achieved  and 
significant  delays  occurred  after  the  Columbia  accident.  In  the  early  years  of  the  ISS  program, 
NASA  envisioned  a  new  United  States  crewed  vehicle  that  would  serve  as  an  ISS  life  raft  and 
crew  transfer  vehicle.  The  planned  US  rescue  vehicle  was  the  victim  of  budget  cuts,  which 
placed  the  Russians  in  the  position  of  sole  provider  of  rescue  services.  The  Russians  launched 
the  Zarya  and  Zvezda  using  their  proven  three-stage  Proton  rocket.  The  MEM  module  is  set  to 
launch  in  December  2011. 


“The  Vision  for  US  Space  Exploration,”  NASA  Report,  February  2004 

It  is  possible  that  with  time  and  budget,  large  replacement  modules  or  equipment  transfer  modules  could  be 
designed  and  launched  as  the  Russians  did  with  their  two  large  modules.  However,  as  of  this  writing,  NASA  has 
no  plans  to  develop  this  capability  or  additional  ISS  components. 
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3.2.3. 1  Russian  Soyuz 

The  initial  NASA  plan  (1990s)  was  to  use 
the  Russian  Soyuz  vehicle  (Figure  24)  as  an 
astronaut  transfer  vehicle  and  to  initially  serve  as 
the  life  raft  until  the  planned  US  crew  rescue 
vehicle  arrived.  When  this  didn’t  happen  the 
Russians  took  responsibility  for  this  role  full  time. 

The  Russian  plan  was  always  to  transport  their 
crews  on  the  Soyuz  and  to  transport  any  fulltime 
ISS  crew  as  needed  and  as  funded  by  the  US.  The 
Soyuz  normally  remains  docked  to  the  Russian 
module  for  six  months  prior  to  the  return  of  the 

crew  that  launched  with  it.  The  Soyuz  system  figure  24.  Russian  Soyuz  Manned  Vehicle 
weighs  approximately  14,200  pounds  at  launch 

and  consists  of  three  major  elements.  The  top  part  is  the  roughly  spherical  pressurized  orbital 
module  that  can  be  used  for  cargo  storage  and  for  crew  accommodation  during  missions.  This 
module  docks  with  the  ISS.  The  middle  section  is  the  “gumdrop-shaped”  re-entry  module  that 
returns  the  crew  to  earth.  It  can  carry  up  to  three  astronauts.  After  the  de-orbit  bum  to  slow  the 
Soyuz,  the  capsule  separates  and  follows  a  semi-ballistic  path  with  normal  parachute  landings  on 
land  in  Kazakhstan  in  central  Asia.  The  third,  lowest  part  of  the  Soyuz  is  the  service  module, 
which  contains  instmmentation,  power  and  propulsion  systems. 

3.2.3. 2  Russian  Progress 

The  Russians  were  always  expected  to 
provide  Progress  vehicle  launches  to  supply  food, 
water,  oxygen  and  other  needed  supplies  (Figure 
25).  This  proven  space  vehicle  has  had  a  good 
record  of  on  time  deliveries  with  no  problems. 

The  vehicle  is  normally  operated  as  an  expendable 
vehicle  that  is  allowed  to  burn  up  in  the 
atmosphere  after  de-orbiting.  As  a  derivative  of 
the  Soyuz  spacecraft,  it  has  the  same  basic 
stmcture  but  lacks  the  equipment  to  allow 
astronauts  to  ride  inside  during  launch.  During 
normal  operation,  it  is  launched  with  a  full  load  of 
new  cargo  and  docked  with  the  ISS.  The  cargo 
capacity  is  much  smaller  than  that  of  the  Space 
Shuttle,  with  the  size  of  cargo  limited  by 
relatively  small  hatches  through  which  cargo  is  transferred  to  ISS.  The  Progress  vehicle  provides 
a  maximum  pressurized  cargo  capability  in  the  1800  kg  range.  Prior  to  the  arrival  of  the  next 
Progress  vehicle,  it  is  filled  with  waste  and  de-orbited.  The  Progress  is  launched  with  the  same 
Soyuz  A2-class  booster  (also  designated  in  some  arenas  as  the  SL-4)  that  launches  the  Soyuz 
capsule.  This  booster  is  derived  from  the  same  original  Korolyov  design  that  launched  Sputnik, 
many  Earth-orbiting  unmanned  research  and  military  craft,  and  every  cargo  and  crew  flight  in 


Figure  25.  Russian  Progress  Unmanned 
Cargo  Vehicle 
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support  of  their  human  space  effort.  After  over  1000  launches  of  its  different  variants,  the 
Soyuz-class  booster  is  unparalleled  in  the  world’s  space  launch  systems  for  reliability. 


3,2,4  Japanese  Projects 

The  Japanese  have  been  steadfast  investors  in  the  ISS  program  and  have  provided 
significant  engineering  support.  In  the  launch  service  arena,  they  developed  the  unmanned  H-11 
Transfer  Vehicle^^  (Figure  26),  which  was  initially  launched  by  the  Japanese  expendable  booster, 
the  H-llB  in  September  2009.  The  vehicle 
capability  in  the  5.5  metric  ton  range. 


provides  both  pressurized  and  unpressurized  cargo 


3,2,5  European  Projects 

The  European  ATV  (Figure  27)  is 
an  expendable,  automated  cargo  transfer 
vehicle  that  is  launched  on  the  Ariane  V 
expendable  rocket.  The  first  ATV  (named 
Jules  Verne)  successfully  completed  its  first 
mission  to  the  ISS  on  June  20,  2008.^^  The 
ATV  successfully  transferred  over  800  kg 
of  fuel  to  the  Russian  Zvezda  module  along 
with  other  supplies.  The  ship  also  demonstrated 
its  ability  to  boost  the  ISS  to  a  higher  orbit.  The 
European  Space  Agency  has  committed  to  five 
vehicles  over  the  2008-2013  period.^"^ 


3,2,6  Commercial  Capabilities 

NASA  would  prefer  to  provide 
transportation  for  crew  and  cargo  to  the  ISS  by 
using  US  sources  to  keep  the  dollars  in  the  US  and 
to  encourage  US  development  of  such  systems. 
NASA  has  already  invested  $500M  to  stimulate 
commercial  launch  sources  to  support  the  ISS  after 
2010.  The  investments  require  the  commercial 
sources  to  demonstrate  various  levels  of 
capability  that  will  eventually  culminate  in  their 
ability  to  reach  and  dock  with  the  ISS. 


Figure  26,  Japanese  Unmanned  H-II 
Transfer  Vehicle 


Figure  27.  European  Unmanned  Automated 
Transfer  Vehicle 


®  Statement  of  Administrator  Michael  Griffin  to  the  Subcommittee  on  Space,  Aeronautics  and  Related  Sciences,  15 
November  2007 

“Jules  Verne  Refuels  the  International  Space  Station,”  Science  Daily,  20  June  2008. 

^  Statement  of  Administrator  Michael  Griffin  to  the  Subcommittee  on  Space,  Aeronautics  and  Related  Sciences,  15 
November  2007 
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Under  the  NASA  Commercial  Orbital  Transportation  Services  (COTS)  program,  Space 
Exploration  Technologies  Corporation  (SpaceX)  and  Orbital  Sciences  Corporation  were  selected 
to  develop  commercial  cargo  delivery  capabilities  for  the  ISS. 

Both  plan  to  eventually  also  offer  crew  launch  and  return 
capabilities. 

SpaceX  is  developing  a  family  of  launch  vehicles 
intended  to  reduce  the  cost  and  increase  the  reliability  of  access 
to  space.  Their  design  and  manufacturing  facilities  are  in 
Southern  California  by  the  Los  Angeles  Airport.  Their 
propulsion  development  and  structural  test  facilities  are 
located  in  central  Texas.  Their  launches  will  take  place  from 
Cape  Canaveral,  Florida. 

The  SpaceX  Falcon  9  launch  vehicle  and  Dragon  spacecraft  will  be  used  for  cargo,  and 
later  crew,  delivery  to  the  ISS.  Falcon  9  is  a  2  stage  launch  vehicle  powered  by  LOX/RP  engines. 
The  first  stage  is  intended  to  be  reusable.  The  Dragon  spacecraft  has  a  flexible  cargo  and  crew 
configuration  and  is  also  recoverable.  Pressurized  cargo  will  be  transported  inside  the  capsule 
while  unpressurized  cargo  will  be  located  in  an  aft  “trunk”.  The  crew  configuration  will  be  able 
to  accommodate  up  to  7  crew  members  per  flight. 

The  initial  test  of  the  full  up  version  of  the  Falcon  successfully  placed  a  qualification  unit 
of  the  Dragon  capsule  into  earth  orbit  in  the  spring  of  2010.  The  first  demonstration  flight  to  ISS 
is  scheduled  for  the  third  quarter  of  2010. 

Orbital’s  COTS  operational  systems  consists  of  the  Taurus  II  launch  vehicle,  the  Cygnus 
advanced  maneuvering  space  vehicle,  and  all  the  necessary  mission  plaiming  and  operations 
facilities  and  services.  Their  launches  will  take  place  from  NASA’s  Wallops  Flight  Facility  in 
Virginia. 

The  Taurus  II  is  a  two  stage  launch  vehicle  utilizing  LOX/kerosene  engines  for  the  first 
stage  and  a  solid  rocket  motor  for  the  second  stage.  The  Cygnus  visiting  vehicle  is  made  up  of  a 
service  module  and  interchangeable  pressurized  and  unpressurized  cargo  modules.  The 
pressurized  cargo  module  is  similar  to  the  MPLM  developed  for  the  ISS  by  Alenia,  which  is  a 
partner  with  Orbital  for  the  COTS  program. 

The  first  demonstration  flight  to  the  ISS  is  scheduled  for  the  second  quarter  of  201 1 . 


Figure  29.  Orbital  Sciences 
Cygnus  Unmanned  Cargo 
Vehicle 


3,3  Development  Challenges 

The  ISS  has  been  an  incredible  success  story,  but  has  nevertheless  had  many  interesting 
challenges  to  overcome.  The  following  are  meant  to  represent  a  sampling  of  the  engineering 
challenges  and  the  approaches  to  solve  them. 


Figure  28.  US  SpaceX 
Unmanned  Cargo  Vehicle 
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3,3.1  Technology  Readiness  and  Obsolescence 

A  major  issue  with  any  lengthy  aerospaee  development  program  is  the  readiness  of  the 
teehnology  ehosen.  If  the  designer  and  systems  engineer  ehoose  teehnologies  that  are  already  in 
use,  they  may  become  obsolete  by  the  time  the  system  is  deployed  or  during  its  early  life. 
Choosing  cutting  edge  or  unproven  technologies  also  risks  delays  and  cost  increases  as  the 
technology  is  matured.  During  the  developmental  phase  of  the  ISS,  the  design  underwent  a 
capabilities-based  assessment,  where  along  with  the  fundamental  mission  capabilities,  tasks, 
attributes  and  performance  metrics,  the  gaps,  shortfalls,  redundancies  and  risk  areas  were 
identified  and  proposed.  Many  of  these  solutions  required  extensive  validation  of  the  underlying 
technology  to  be  used  in  space.  Even  though  many  of  the  technologies  or  prototypes  were  tested 
on  the  ground,  the  effects  of  microgravity,  radiation,  and  human  factors  could  not  easily  be 
reproduced  with  the  desired  duration  and  accuracy.  To  minimize  this  risk,  most  of  the  systems 
that  were  chosen  had  already  flown  on  the  MIR,  Shuttle,  and  Spacelab  or  had  been  developed 
and  tested  as  part  of  Space  Station  Freedom.  This  approach  created  a  risk  of  long  term 
obsolescence  but  reduced  the  upfront  schedule  and  cost  risk.  A  case  in  point  is  the  early  baseline 
of  the  Solar  Dynamic  (SD)  power  subsystem  that  was  to  supplant  the  later  photovoltaic  arrays. 
The  SD  power  subsystem  was  highly  efficient  in  comparison  to  the  photovoltaic  arrays,  but 
because  of  high  up  front  development  and  validation  costs,  and  the  known  reliability  of 
photovoltaic  arrays,  the  SD  system  was  later  abandoned. 


NASA  has  conducted  extensive  research  in  this  area  and  helped  to  create  the  Technology 
Readiness  Levels,  shown  in  Table  2  below: 

Table  2.  Technology  Readiness  Levels 


TRL  1  Basic  principles  observed  and  reported 
TRL  2  Technology  concept  and/or  application  formulated 
TRL  3  Anal}dical  and  experimental  critical  function  and/or  characteristic 
proof-of-concept 

TRL  4  Component  and/or  breadboard  validation  in  laboratory  environment 
TRL  5  Component  and/or  breadboard  validation  in  relevant  environment 
TRL  6  System/subsystem  model  or  protot}q)e  demonstration  in  a  relevant 
environment  (ground  or  space) 

TRL  7  System  protot}q)e  demonstration  in  a  space  environment 
TRL  8  Actual  system  completed  and  “flight  qualified”  through  test  and 
demonstration  (ground  or  space) 

TRL  9  Actual  system  “flight  proven”  through  successful  mission  operations 


The  idea  is  to  select  a  technology  for  a  new  system  that  will  reach  maturity  (TRL  9)  at  the 
same  time  as  the  deployment  of  the  target  system.  For  most  major  aerospace  programs,  the 
technologies  are  normally  chosen  at  a  TRL  6  or  7  for  a  new  program  three  or  four  years  in 


“Reduction  of  Space  Exploration  Risk — Use  of  ISS  as  a  Testbed  for  Enabling  Technologies,”  by  Ilia  Rosenberg, 
Michael  Clifford,  and  Joe  Bryant,  The  Boeing  Company,  AAI  paper. 
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advance  of  deployment.  In  the  ease  of  the  ISS,  some  of  the  systems  are  not  easily  upgradeable  or 
replaeeable,  so  eare  must  be  taken  in  choosing  the  best  system  or  teehnology  that  will  provide 
long  service  but  won’t  represent  a  schedule  or  eost  risk  due  to  delayed  development. 

3,3,2  Use  of  Probabilistic  Risk  Assessment 

NASA  uses  a  variety  of  standard  risk  approaehes  for  the  ISS,  but  in  particular  specifies 
the  Probabilistie  Risk  Assessment  (PRA)  proeedure  that  details  a  struetured  risk  management 
proeess  for  system  development.  The  NASA  requirement^^  states: 

Probabilistie  Risk  Assessment  (PRA)  is  a  eomprehensive,  struetured,  and  logieal 
analysis  methodology  aimed  at  identifying  and  assessing  risks  in  eomplex 
technological  systems.  PRA  is  generally  used  for  low-probability,  high- 
eonsequence  events  for  which  limited  statistical  data  exist.  Its  applieation  is 
targeted  at  risk  environments  eommon  within  NASA  that  may  involve  the 
eompromise  of  safety,  inelusive  of  the  potential  loss  of  life,  personal  injury,  and 
loss  or  degradation  of  high-value  property  that  may  be  found  in  NASA  mission- 
related  programs. 

PRA  is  a  deeision  support  tool  to  help  managers  and  engineers  find  design  and  operation 
weaknesses  in  eomplex  space  systems.  It  allows  them  to  systematically  uncover  and  prioritize 
safety  improvements.  PRA  eharaeterizes  risk  in  terms  of  three  questions  ealled  the  triplet 
definition  of  risk: 

1 .  What  can  go  wrong? 

2.  How  likely  is  it? 

3.  What  are  the  consequences? 

These  simple  three  questions  (often  ealled  the  Triplet  Definition  of  Risk)  are  then 
expanded  into  a  full  scope  seenario-based  PRA  proeess. 

1.  Objectives  Definition 

2.  System  Familiarization 

3.  Identification  of  Initiating  Events  (lEs) 

4.  Scenario  Modeling 

5.  Failure  Modeling 

6.  Data  Collection,  Analysis,  and  Development 

7.  Quantification  and  Integration 

8.  Uncertainty  Analysis 

9.  Sensitivity  Analysis 

10.  Importance  Ranking 


NPR  8705.5  Probabilistic  Risk  Assessment  Procedure  for  NASA  Programs  and  Projects.  NASA  Office  of  Safety 
and  Mission  Assurance,  July  12,  2004 
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If  these  struetured  steps  are  followed,  the  key  to  sueeess  or  failure  is  how  well  management  is 
integrated  into  the  proeess,  along  with  the  subject  matter  experts,  and  how  that  management 
believes  and  acts  upon  the  outputs 

3,3,3  Russian  Contribution  and  Risk 

The  decision  to  invite  the  Russians  to  participate  was  a  complicated  decision  that 
involved  numerous  political,  operational,  financial/schedule  and  technical  considerations. 

■  From  a  political  viewpoint,  the  US  and  USSR  had  just  ended  the  Cold  War  (at  great  expense 
to  both)  and  the  USSR  had  split  into  a  number  of  independent  nations  with  Russia  as  the 
dominant  force.  The  Soviets  (and  now  Russians)  had  extensive  space  experience  and 
technology  that  might  be  of  value  to  the  new  ISS  that  was  being  proposed.  However,  the  US 
and  the  Russians  had  limited  experience  working  together  (Apollo-Soyuz)  to  begin  a  major 
cooperative  effort  so  soon  after  the  Cold  War  ended.  On  top  of  these  major  political 
problems,  there  were  significant  cultural  issues  that  would  impact  the  systems  engineering 
challenge. 

■  Operationally,  the  Russians  had  extensive  on-orbit  experience.  The  MIR  was  the  state  of  the 
art  in  space  station  technology  at  the  time.  The  US  had  been  launching  Shuttle  missions  with 
many  different  missions  utilizing  the  Shuttle’s  cargo  bay,  but  had  little  recent  experience  in 
long-term  space  habitation  or  system  operation.  NASA  and  its  contractors  did  have  designs 
for  new  equipment/facilities  and  some  older  technology,  but  significant  development  and 
production  remained  before  the  US  and  its  original  partners  would  have  been  operational  on 
orbit. 

■  Russia  was  in  financial  straits  following  the  breakup  of  the  Soviet  Union  and  the  space 
program  was  not  high  as  a  priority  for  funding.  A  key  driver  was  the  US  initiative  to  retain 
Soviet  aerospace  engineers  and  scientists  for  work  on  aerospace  projects  (particularly  ISS).  A 
concern  at  the  time  was  that  unemployed  scientists  and  engineers  from  this  sector  could  be 
easily  attracted  to  work  for  interests  not  in  keeping  with  long  term  US  security  needs  if  not 
gainfully  employed  on  ISS.  A  large  infusion  of  cash  was  needed.  This  was  the  primary 
reason  the  US  (via  NASA)  was  driven  to  pay  for  Russian  contributions  to  the  ISS,  rather  than 
in  kind  trades  as  with  all  other  ISS  partners.  The  inclusion  of  key  Russian  station  elements 
offered  the  chance  for  NASA  to  reduce  cost  and  schedule  overall.  NASA  was  under  pressure 
to  deliver  a  space  station  at  a  reasonable  cost,  and  the  Russian  modules  were  already  started 
and  most  of  the  systems  were  flight  proven. 

■  In  the  initial  assessment,  the  Russian  participation  should  allow  the  ISS  to  accelerate  or  at 
least  meet  a  shorter  schedule  that  would  put  elements  into  orbit  by  2000.  The  Russian 
modules/systems  were  flight  proven  and  appeared  to  offer  less  cost,  schedule,  and  technical 
risk  in  comparison  to  the  challenges  of  NASA  designing  and  building  some  critical  elements. 

While  the  Russian  systems  were  considered  off  the  shelf,  they  still  presented  some  risk 
compared  to  the  NASA  SE  protocols  and  system  requirements.  As  off-the-shelf  modules  (and 
thus  high  TRLs),  they  had  been  initially  designed  for  the  MIR  or  its  replacement.  More 
important,  the  Russians  had  different  engineering  and  system  design  requirements  that  did  not 


“Russian  Compliance  with  Safety  Requirements,”  GAO/T-NSIAD-00-128,  16  March  2000 
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always  meet  the  newer  ISS  requirements.  NASA  engineers  had  to  issue  waivers  for  the  early 
modules  that  acknowledged  the  additional  risks  and  provided  future  fixes  where  necessary — 
such  as  for  MMOD  shielding  or  noise.  Russian  MMOD  vulnerability  and  acoustic  level 
exceeding  requirements  were  respectively  the  number  1  and  2  program  risks  in  2000.  Currently, 
the  acoustic  levels  are  no  longer  on  the  top  list  of  concerns  for  ISS. 

3.3.4  Spiral  Construction  Approach  and  Multi-configuration  issues 

A  major  task  for  the  ISS  program  dated  back  to  the  Space  Station  Freedom  effort.  The 
build-up  sequence  of  the  Space  Station  Freedom  was  problematic  and  considered  high  risk  by 
several  of  the  systems  engineers  of  the  day.  While  the  total  system  design  was  acceptable,  the 
SE  process  at  the  time  was  only  beginning  to  recognize  the  implications  of  spiral  construction 
on-orbit.  For  ISS,  spiral  construction  was  the  integrated  design,  configuration  and  assembly  of 
up  to  forty  elements  that  had  to  operate  as  a  fully  functioning  ISS  at  each  sub-assembly  stage. 
This  meant  that  full  operating  procedures,  software  builds,  center-of-gravity  and  station  moments 
of  inertia  all  had  to  be  developed  for  each  configuration.  This  spiral  construction  and  its  multiple 
interim  configurations  drove  the  requirements  for  detailed  Multi-element  Integrated  Testing 
(MBIT) — though  it  was  not  actually  implemented  until  a  few  years  into  the  program. 

One  of  the  senior  systems  engineers  commented  that: 

“Systems  engineering  involved  communications,  so  as  you  go  between  divisions, 

NASA  centers  and  international  partners,  this  makes  things  more  difficult  to 
engineer.  Communication  bandwidth  in  these  cases  is  essential.  A  key  is  to  make 
interfaces  as  simple  as  possible,  then  simplify  further.  This  is  more  critical  when 
crossing  organizational  boundaries.  If  its  crossing  government  (or  country) 
boundaries  and  its  anything  other  than  structure,  it  too  complicatedl  ” 

3.3.5  Computer  Hardware  and  Software 

The  ISS  onboard  computing  architecture  is  a  mixture  of  radiation-hardened  Intel  386  chip 
based  ISS  mission  computers  for  station  housekeeping,  environmental,  and  station-keeping 
duties  combined  with  scores  of  standardized  commercial,  off-the-shelf  (COTS)  notebook 
computers  that  the  crews  can  use  as  interface  devices  to  the  more  controlled  software 
environment  of  the  systems  and  payloads,  or  use  “off  net”  for  email,  internet  protocol  telephone, 
training,  and  a  host  of  other  non-system  uses.  A  conscious  effort  was  made  to  use  COTS 
products  where  possible  with  minimal  modifications  while  complying  with  safety  to  reduce  cost 
and  risk  to  the  program.  The  major  critical  computers  provided  significant  capacity  to 
accommodate  future  requirements.  The  entire  ISS  system  was  designed  as  a  distributed 
processing  system  over  major  nodes  (multiplexors)  with  each  dependent  on  a  major  computer 
system.  The  standard  station-keeping  functions  were  on  the  ISS  computers.  The  non-critical  and 
experimental  support  software  is  configured  on  the  laptops. 

The  use  of  laptop  computers  was  not  originally  a  major  part  of  the  program.  In  fact,  a 
local  area  network  for  support  computers  had  to  be  retrofitted  to  the  ISS  after  launch. 
Originally,  two  entire  racks  of  computer  interface  equipment  known  as  Multi-Purpose 
Application  Consoles  were  to  have  been  built  as  the  main  computing  and  training  interface 
aboard  the  ISS,  built  and  programmed  from  scratch  to  Mil  specs,  using  ADA  and  the  X- 
Windows  software  standard,  similar  to  the  systems  used  in  mission  control.  Beginning  in  2003, 
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special  studies  were  initiated  to  build  upon  the  lessons  of  the  Space  Shuttle  program’s  experience 
with  the  Portable  General  Support  Computer  (PGSC).  The  PGSC  was  used  independently  of  the 
Shuttle  General  Purpose  Computers,  but  had  rapidly  enabled  many  new  capabilities  for  the  crew. 
These  studies  led  to  a  host  of  concepts,  including  onboard  electronic  training  and  procedures, 
phone  services,  video  uplink,  and  even  command  and  control.  A  special  safety  position  paper 
was  drawn  up  to  define  the  functions  in  command  and  control  that  could  be  assigned  to  a 
criticality-3  off-the-shelf  hardware/software  system,  and  those  that  must  be  assigned  to 
configuration-controlled  software  development  processes  and  fault-tolerant  hardware. 
Generally  this  boiled  down  to  the  idea  that  the  COTS  system  could  display  any  data,  and  could 
send  individual  crew  commands  under  an  arm/check/fire  transmission  concept.  This  prevented 
the  COTS  notebook  from  taking  any  active  role  in  the  automated  critical  systems  processes,  but 
enabled  tremendous  enhancements  to  situational  awareness  and  to  system  debugging  and  control. 

The  custom-built  shuttle  Grid  PGSC  computer  has  been  recently  replaced  by  COTS  IBM 
Thinkpad  computers,  with  vastly  greater  power  and  enough  robustness  to  meet  the  demands  of 
spaceflight.  However,  such  COTS  computers  had  to  be  qualified  and  modified  to  make  them 
fully  safe  for  operation  on  the  shuttle  or  ultimately  the  ISS.  The  major  changes  that  had  to  be 
made  included: 

1 .  The  laptops  had  to  be  modified  with  fans  to  handle  cooling.  In  microgravity  the  warm  air 
generated  around  the  computer  circuit  board  does  not  move;  it  tends  to  stay  in  place 
unless  forced  air  ventilation  is  provided.  Once  the  heat  is  removed,  NASA  then  has  to 
determine  if  the  ISS  or  its  modules  can  handle  the  heat  that  is  rejected.  For  instance,  the 
Shuttle  had  a  restriction  against  devices  that  produced  heat  greater  than  113  degrees 
Fahrenheit. 

2.  All  internal  circuit  boards  and  printed  connection  areas  had  to  be  conformally-coated 
with  dielectric  film,  to  avoid  the  possibility  of  small  conducting  debris  floating  against 
the  circuits  and  shorting  them  out  in  the  3-phase  flows  that  are  typical  of  zero-G  cabin 
atmospheres. 

3.  Power  adaptors  were  needed  to  allow  the  computers  to  be  plugged  in  to  either  module 
with  28  VDC. 

4.  The  laptop  had  to  function  normally  in  low  pressure  (10  psia)  compared  to  normal  earth 
pressure  of  14.7  psia.  (This  is  more  of  a  constraint  onboard  the  Shuttle  than  aboard  the 
ISS,  whose  atmosphere  is  regulated  to  sea  level  pressure  at  all  times:  However,  for 
commonality  and  the  many  advantages  it  brings,  all  notebook  computers  are  certified  for 
either  vehicle.) 

5.  The  laptop  had  to  be  attached  to  a  stable  surface  to  allow  the  astronaut  to  use  it  without 
both  floating  away;  Velcro  was  the  common  solution. 

Obsolescence  was  mainly  a  problem  with  laptop  computers  with  a  resulting  major 
configuration  question  of  how  to  upgrade  and  how  often.  Obviously,  NASA  and  its  partners 
could  buy  new  laptops  every  month  to  capture  the  latest  technology.  The  major  expense  was 
maintaining  back  compatibility  with  data  and  software  along  with  modifications  to  make  them 
flight-safe.  NASA  currently  has  a  replacement  cycle  that  is  roughly  every  four  years. 
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Despite  the  NASA  poliey  of  using  COTS  hardware  and  software  if  possible,  there  is  a 
eost  in  making  them  space-ready.  At  a  minimum,  the  cost  to  qualify  includes  ground  testing  and 
safety  checks  to  make  sure  there  are  no  surprises  in  orbit. 

Even  with  a  multi-billion  dollar  ISS,  the  computers  are  not  immune  to  such  mundane 
threats  as  computer  viruses  or  hackers.  In  August  of  2008,  the  message  traffic  between  ground 
controllers  and  the  astronauts  revealed  that  some  of  the  computers  on  board  had  been  infected 
with  a  common  gaming  virus  worm  that  is  used  to  gather  information  from  the  infected  computer 
and  then  transmit  it  to  the  remote  attacker.  In  the  end,  this  problem  was  minor  and  apparently 
caused  no  damage,  but  ensured  virus  protection  on  the  ISS  computers. 

The  ISS,  its  subsystems,  and  many  space-related  experiments  employ  a  wide  variety  of 
software.  When  possible,  COTS  software  was  used,  especially  for  management  or 
administrative  tasks.  The  laptops  are  all  Windows-based  and  use  the  standard  Microsoft 
products  along  with  other  more  technical  off-the-shelf  packages.  There  are  specific  programs 
written  to  control  experiments  and  non-critical  equipment  that  the  astronauts  use  on  each  flight. 

An  example  of  a  more  sophisticated  software  application  is  within  the  Mobile  Servicing 
System  (MSS),  which  is  the  system  composed  of  the  Canadarm  2  robotic  arm  that  has  been 
critical  in  the  construction  and  maintenance  of  the  ISS.^^  The  operation  of  this  equipment  is 
safety-critical,  so  a  software  approach  for  “life-critical”  operations  was  chosen.  In  this  case 
ADA  was  the  language  of  choice.  Some  system  engineers  believe  ADA  is  a  “dead  language” 
which  was  used  in  the  Department  of  Defense  in  the  late  1970s.  However,  it  is  still  the  language 
of  choice  for  many  system  developers  for  applications  requiring  safety,  low  cost  maintenance, 
and  near  perfect  reliability.  At  the  time  of  Space  Station  Freedom,  ADA  was  the  US  space 
systems  required  standard,  and  so  was  used.  ISS  system  developers  stated  that: 

“The  most  important  safety  features  that  make  ADA  ideal  for  development  of fail¬ 
safe  software  include  its  information-hiding  capability,  its  ability  to  provide  re- 
useable  code  and  its  “strong  typing”,  which  helps  detect  and  solve  many  types  of 
coding  errors  at  compile  time,  very  early  in  the  development  cycle.  ” 

While  very  robust  languages  like  ADA  prevent  most  errors  from  ever  making  it  to  orbit,  long 
term  maintenance  and  changes  present  significant  challenges,  especially  when  considering  the 
integration  of  the  module,  control  systems  and  experimental  packages.  Here  the  software  must 
be  routinely  tom  down  and  rebuilt.  According  to  Lehman's  laws^*^  of  software  evolution: 

“The  functionality  of  a  system  must  increase  continually  in  order  to  maintain  user 
satisfaction  over  its  lifecycle.  At  the  same  time  the  software  complexity  increases  unless 
something  is  done  to  reduce  it.  ” 


“Has  the  First  Extraterrestrial  (Computer)  Virus  been  discovered  on  the  Space  Station,”  by  Ian  O’Neill,  Space 
Reference,  Inc.  August  26,  2008. 

“Case  Study:  Space  Station  Robot  Embeds  ADA,”  Rovert  Devar,  Ada  Core  Technologies,  COTS  Journal.  March 

2002, 

M.M.  Lehman,  D.E.  Perry,  J.F.  Ramil,  W.M.  Turski,  and  P.  Wemick,  “Metrics  and  Laws  of  Software  Evolution 
-  The  Nineties  View”,  In  Proceedings  of  the  4th  International  Symposium  on  Software  Metrics,  Metrics  97, 
Albuquerque,  New  Mexico,  IEEE  Comp.  Soc.  or.  n.  PR08093,  November  5-7,  1997,  pp.  20-32. 
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Particularly  in  the  preliminary  design  phases  of  the  complex  ISS  data  management 
system,  a  strong  typing  language  like  ADA  was  a  huge  hindrance  to  the  much-needed  rapid 
prototyping  of  an  enormously  complex  system.  Rapid  prototyping’s  “sloppy”,  instant- iteration 
capability  might  allow  cooperating  engineers  to  diseover  and  to  work  out  major  arehiteeture  and 
interfaee  problems  in  an  environment  that  quickly  grows  progressively  more  “flight  like.”  The 
ISS  program  adopted  a  formal  requirements  definition  proeess  that  led  from  system  architecture 
requirements  to  Interfaee  Requirements  to  Interface  Control  specifications  before  a  single  line  of 
software  could  be  written  and  explored.  Such  a  plan,  while  useful  up  to  a  manageable 
complexity  level,  put  a  burden  on  the  software  and  command  and  control  systems  engineers  to 
imagine  all  the  intrieaeies  of  this  multiple-interfaced  system,  and  to  capture  all  necessary 
interfaces,  without  a  fully-functional  test-bed. 

Further,  particularly  in  the  earliest  days  of  the  development,  the  agency  did  not  have  a 
strong  enough  background  in  the  advantages  and  techniques  of  object-level  programming,  so 
most  software  planning  was  more  refieetive  of  (and  appropriate  to)  the  monolithie  code  that  was 
typical  of  the  Space  Shuttle  General  Purpose  Computers  or  the  Mission  Control  Complex,  and 
not  to  a  system  of  over  two  dozen  eooperating  parallel  proeessors. 

A  manifestation  of  the  lack  of  use  of  true  object  programming  was  the  persistence  of 
what  can  be  termed  “push  rod”  command  and  control.  Although  the  grand  vision  of  the  software 
arehiteeture  had  multiple  tiers  of  higher  and  higher  automation  overseeing  the  low-level  sensors 
and  effectors  working  within  an  automated  proeess  or  series  of  cooperating  proeesses,  the  natural 
desire  of  the  ground  operators  and  astronauts  was  to  have  ultimate  override  capability  at  the 
effector  and  sensor  level.  Thus  for  every  automated  applieation  “object”,  the  arehitects  were 
ehallenged  to  provide  individual  command  paths  to  bypass  virtually  every  function  in  the  object. 
Sensor  and  effeetor  objects  were  originally  replicated  at  every  level  of  the  arehiteeture,  adding 
more  and  more  resource  requirement  to  the  higher  level  tiers,  instead  of  less.  Thus,  all  tiers  of 
automation  hierarehy  reverted  to  massive  “pass  through”  relays  of  low-level  commands  for  the 
operators  down  to  the  individual  effectors.  Automation  would  come  later,  and  the  eomplex 
system  was  thus  arehiteeted  from  the  bottom  up,  rather  than  the  top  down. 

One  study eonsidered  the  challenges  to  ISS  software  system  engineers  of  how  to 
respond  to  design  problems  diseovered  during  testing  and  how  to  incorporate  new  features  into 
the  software  design  after  launch  and  initial  implementation.  The  study  focused  on  the  ISS 
Operations  Control  Software  (OCS),  since  it  was  a  good  example  of  a  complex  software  system 
with  extensive  testing  early  on,  and  then  a  long  maintenance  period  once  the  system  was 
deployed.  The  study  eonsidered  both  oases:  constructive  fixes  early  on  and  adaptive  fixes  during 
operations.  The  study  concluded: 

1.  Lehman’s  thesis  was  confirmed:  In  both  maintenanoe  soenarios,  the  altered 
designs  inoreased  the  oomplexity  of  the  system  compared  to  the  original 
architecture. 


’’  “The  Space  Station  Operations  Control  Software:  A  Case  Study  in  Architecture  Maintenance,”  Robert  Leitch  and 
Eleni  Stroulia,  Proceedings  of  the  34*  Hawaii  International  Conference  on  Sciences,  2001. 
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2.  During  maintenance,  re-factoring  operations  helped  alleviate  the  increased 
complexity  introduced  by  new  architectural  elements  such  as  hardware  and 
software. 

3.  Additions  as  opposed  to  changes  are  often  more  desirable  to  developers,  because 
they  do  not  risk  “breaking”  already  developed  code. 

4.  Engineers  tend  to  consider  implementation  cost  more  than  maintenance  cost — not 
necessarily  best  for  long  term  operation  or  ISS  life  cycle  cost.  This  tendency  is 
also  a  by-product  of  the  U.S.  government’s  year-to-year  funding  process  which 
forces  decisions  early  in  the  system  life  cycle  thus  impacting  the  operational 
costs. 

3,3,6  Power  Systems 

The  power  system  for  the  ISS  is  the  largest  space  based  electrical  power  system  (EPS) 
ever  developed  and  successfully  operated.  The  EPS  was  designed  as  a  hybrid  120-volt  DC  US 
segment  and  a  28/120  volt  Russian  segment.  The  two  systems  are  independent,  but  can  be 
interconnected  via  dc  converters.  The  split  system  derives  from  the  early  decision  to  use  the 
Russian  modules  that  were  essentially  off-the-shelf  and  space  proven  (low  risk).  The  power  flow 
diagram  is  shown  in  Eigure  30. 

The  US  segment  of  the  EPS  is  a  channelized,  load  following  (i.e.,  points  at  the  sun) 
network  of  extensive  solar  photovoltaic  arrays,  batteries,  voltage  converters,  remote  controlled 
switchgear,  and  power  routing  cables. 


“The  Electric  Power  System  of  the  International  Space  Station — A  Platform  for  Power  Technology 
Development,”  Eric  Gietl,  Edward  Gholdston,  Bruce  Manners,  and  Rex  Delventhal,  NASA/TM-2000-2 10209,  June 
2000. 
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Figure  30.  Single  Channel  Power  Flow  Diagram 

The  ISS  has  eight  solar  array  wings  that  when  fully  extended  are  eaeh  35  meters  long  by 
12  meters  wide.  The  wings  are  eonstantly  adjusted  to  maintain  an  optimal  traeking  of  the  sun, 
simultaneously  aehieving  orbital  power  balance,  minimum  depth  of  battery  discharge,  and 
minimized  frontal  area  projected  to  the  ram  direction  (thus  minimizing  ISS  drag,  and  saving 
propellant),  while  constantly  avoiding  differential  heating  of  the  slender  mast  longerons,  that 
could  lead  to  very  dangerous  structural  fatigue.  Because  the  station  is  in  and  out  of  the  sun 
approximately  every  ninety  minutes,  the  ISS  contains  a  large  battery  set  to  store  the  energy 
during  eclipse.  The  US  system  uses  actively-cooled  nickel-hydrogen  batteries  specifically 
designed  for  high  (40,000)  charge/discharge  cycles. 

A  critical  requirement  is  to  constantly  track  the  sun  with  the  arrays  and  the  station  to 
maximize  photovoltaic  solar  cell  output.  A  key  part  of  the  system  is  the  solar  array  rotating  joint 
(SARJ),  which  rotates  the  large  solar  panels.  In  fall  2007,  the  ground  team  noticed  unusual 
vibrations  when  the  starboard  SARJ  rotated,  along  with  higher  than  normal  current  usage. 
During  a  scheduled  EVA  in  October  2007,  astronauts  did  a  visual  inspection  and  found  the 
exterior  to  be  free  of  damage — but  once  they  removed  covers  over  the  motor  and  gears,  they 
found  metal  shavings,  indicating  either  debris  left  during  assembly,  or  more  likely,  the  gears 
were  chewing  themselves  up.  The  initial  fix  was  to  lock  down  the  unit  and  not  adjust  those  solar 
panels;  but  long  term,  this  would  seriously  diminish  electrical  output — at  a  time  when  NASA 
was  hoping  to  increase  electrical  production  for  the  upcoming  six-person  crews.  Fortunately, 
during  several  2008  EVAs,  the  astronauts  were  able  to  replace  the  bearings  and  other  joint  parts 
and  thoroughly  lubricated  the  system  to  make  the  joint  operational. 
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3,3,7  Micrometeoroid  and  Orbital  Debris  (MMOD)  Protection 

For  an  aircraft  program,  engineers  typieally  worry  about  bird-strikes  while  in  flight  or 
foreign  objeet  damage  (FOD)  that  is  picked  up  on  the  ramps,  taxiways  and  runways.  In  the  case 
of  FOD,  prevention  is  the  major  emphasis  area  with  some  degree  of  damage  tolerance  built  in  to 
the  system.  Bird  strikes  are  normally  defended  against  with  material  strength  and  engines  that 
can  tolerate  bird  ingestion  and  allow  the  aireraft  to  land  safely.  For  space  vehieles,  there  is  a 
major  differenee:  eaeh  pieee  of  micrometeoroid  or  spaee  debris  eontains  large  amounts  of  kinetie 
energy  as  they  travel  at  extremely  high  veloeities; 

Ek=l/2mV^  where  V  is  speed  and  m  =  p^7r{^f  is  the  partiele  mass  with  density  p 

Even  small  mierometeoroid  partieles  ean  have  densities  that  range  from  7-8  g/em  while  smaller 
ones  (mainly  ice)  are  1-2  g/em^.  Typical  space  debris  veloeities  range  from  6-16  km/see  while 
meteorites  can  be  up  to  70  km/see — thus  the  high  veloeity-squared  allows  even  tiny  partieles  to 
have  hazardous  energy  levels. 


Average  Micrometeoroid  Environment  for  iSS  for  year  2007 


The  threat  has  been  characterized  in  several  studies  and  metries  used  to  measure  flux, 
or  the  number  of  micrometeoroid  hits  per  square  meter  per  year  on  an  exposed  surfaee. 
Obviously  with  a  large  station  and  thousands  of  meters  of  exposed  surfaee,  this  is  not  a  trivial 
risk.  A  recent  study  looked  at  various  models  to  predict  the  number  of  hits  and  size  of  the 
projeetiles  with  some  results  shown  in  Figure  31.  The  models  elearly  indicate  that  thousands  of 
small  hits  probably  oecur  every  year  and  this  distribution  is  a  function  of  orbital  path,  altitude. 


“Micrometeoroid  and  Orbital  Debris  Environments  for  the  International  Space  Station,”  Glenn  Peterson  and 
David  K.  Lynch,  Engineering  and  Technology  Group,  The  Aerospace  Corporation,  TR-2008-8570-1,  December  15, 


2007. 


60 


and  speed  of  the  satellite  or  ISS.  At  the  time  of  this  study  (Deeember  2007)  the  authors 
speculated  that: 

""The  calculations  do  not  include  the  as  yet  unknown  change  in  OD  particle 
number  and  distribution  due  to  the  recent  Chinese  AS  AT  experiment.  Such  events 
are  certain  to  increase  the  number  of  orbiting  particles.  Some  people  have 
suggested  that  a  relative  small  number  of  explosions  in  LEO  can  eventually 
render  LEO  space  uninhabitable  for  satellites  because  one  large  particle  can 
cause  an  explosion  that  leads  to  further  particles  that  hit  more  spacecraft  until  a 
runaway  situation  is  reached.  ” 

Since  that  study  came  out,  there  has  been  a  major  collision  in  orbit  between  a  dead  Russian 
satellite  and  US  communications  satellite. Both  were  over  680  kg  (1500  lbs)  in  mass  and 
created  a  debris  field  many  times  larger  than  the  Chinese  ASAT  experiment,  with  thousands  of 
new  smaller  objects  going  in  a  multitude  of  directions.  While  the  collision  occurred  at  an 
altitude  of  790  KM  (about  490  miles),  which  is  well  above  the  ISS  (normally  around  200-240 
miles),  the  debris  will  all  eventually  sink  to  lower  orbits  and  threaten  the  ISS  orbit  as  the  debris 
speed  decays.  Large  debris  from  that  event  was  seen  re-entering  the  atmosphere  over  Texas  as 
early  as  a  week  after  the  collision. 

The  ISS  has  several  means  of  protecting  itself  and  crew  against  impacts  with 
micrometeoroids  and  orbital  debris.  First,  the  ISS  can  be  moved  to  a  different  orbit  if  the  ground 
controllers  (with  radar)  can  discover  and  track  a  potential  threat.  The  ISS  has  been  moved  on 
occasion  to  avoid  any  possibility  of  collision.  NASA  and  the  DOD  (plus  other  countries)  already 
track  over  13,000  objects  larger  than  about  two  inches  known  to  be  in  orbit. 

The  ISS  has  an  outer  skin  and  additional  protective  “curtains”  to  increase  its  protective 
shields.  These  shields  and  outer  skins  are  meant  to  absorb  the  initial  energy  of  a  small  strike  and 
have  the  energy  spread  out  through  the  protective  layer  much  like  a  bullet  hitting  a  bullet-proof 
vest  (see  2. 3. 7. 2).  An  interesting  highlight  of  the  high  importance  of  MMOD  protection  to  the 
ISS  program  is  the  fact  that  the  US  government  allowed  the  technical  export  of  the  “BUMPER” 
hypersonic  ballistic  penetration  software  code  to  all  foreign  ISS  partners  as  the  de-facto  analysis 
standard  to  allow  technical  development  of  better  and  better  protective  strategies.  This  export 
was  quickly  granted,  despite  the  fact  that  such  a  code  has  obvious  military  benefits. 

3,3,8  Test  and  Integration 

3.3. 8.1  ISS  Multi  Element  Integrated  Testing  (MEIT)  Program 

Testing  complex  space  systems  represented  a  major  challenge  to  NASA  and  its  partners. 
Many  of  the  modules  were  developed  in  different  countries  and  delivered  “just  in  time”  for  the 
launch.  Each  module  had  to  be  tested  for  its  own  internal  operation;  then  it  had  to  interface  with 
the  launch  vehicle,  and  finally  it  had  to  work  in  space  while  integrated  with  multiple  modules 
and  systems.  An  early  strategy  at  NASA  to  save  cost  was  coined  as  “Ship  and  Shoot”  which 
implied  the  modules  or  systems  were  delivered  as  late  as  possible  to  the  launch  site  preventing 
extensive  testing,  checked  for  internal  operation  (but  with  little  or  no  testing  when  coupled  with 
other  systems  or  simulators)  and  then  “shot”  into  orbit  where  they  would  be  installed.  The 


“Satellite  Collision  Puts  Hubble  at  Risk,”  ABC  News,  Gina  Sunsiri,  13  Feb  2009. 
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factory-level  and  subsystem  checkouts  were  all  that  might  have  been  planned  or  possible.  Given 
this  approach,  the  modules  were  not  originally  scheduled  to  be  delivered  in  time  to  perform 
additional  testing  at  the  Kennedy  Space  Center. 

By  the  late  1990s  and  with  the  benefit  of  MIR  and  Shuttle  mission  experienee,  NASA 
adopted  a  more  integrated  approach  for  testing.  It  beeame  apparent  that  most  of  the  modules 
and  major  subsystems  would  be  available  prior  to  launeh  for  some  version  of  integrated  testing 
and  limited  ground  assembly  to  imitate  the  final  “on-orbit”  assembly  and  operation.  This 
approach  allowed  for  element-to-element  interface  eapability  to  be  tested  and  verified  as  well  as 
systems  end-to-end  operability  with  hardware  and  software.  To  the  degree  that  hardware  could 
be  physieally  conneeted  in  its  final  orbit  configuration,  it  was  tested  as  such.  Otherwise,  the 
segments  were  connected  with  simulation  hardware.  Four  major  test  eonfigurations  are  detailed 
on  the  following  page  and  were  [Note  the  truss  segment  designations:  Z  for  zenith,  P  for  port, 
and  S  for  starboard.  The  truss  numbers  indicate  the  order  from  the  center.]: 

MBIT  1  -  US  Lab  Module,  Zl,  P6,  SSRMS,  Node  1  (simulated  sinee  it  was  in  orbit) 

MBIT  2  -  SO/MT/MBS,  SI,  PI,  P3/4,  US  Lab  (simulated  sinee  it  was  now  in  orbit) 

MBIT  3  -  IBM,  Node  2,  US  Lab  (simulated  since  it  was  in  orbit) 

Node  2  System  Test  -  Node  2,  US  lab  &  Node  1  (simulated) 

The  MBIT  2  set-up  is  shown  in  Bigures  32  and  33. 

The  results  of  this  MBIT  approach  were  signifieant  and  prevented  major  problems  that 
would  have  been  discovered  only  after  attempting  to  assemble  and  then  test  the  major  elements 
while  in  orbit.  The  MBIT  approaeh  for  funetional  verification  was  a  major  SB  contribution 
from  Boeing  based  on  their  lessons  learned  on  their  777  aireraft  development  program.  In 
partieular,  Boeing  brought  the  Digital  Pre-Assembly  (DPA)  and  Cable  Assessment/Bluid 
Assessment  (CA/BA)  technologies  to  bear,  which  enabled  the  success  of  MBIT.  DPA  ensured 
verification  of  element-to-element  struetural  interfaees  without  interference,  while  CA/BA 
ensured  that  on-orbit  assembled  fluid  and  eleetrieal  lines  would  mate  properly  onee  installed. 
Major  discoveries  on  the  ground  were: 

■  P6  Truss  failed  to  power  up  due  to  Auxiliary  Power  Converter  Unit  under  voltage 
trip  condition. 

■  US  Lab  activation  took  over  36  hours  during  on  ground  first  MBIT  power  up  due 
to  significant  computer/procedure  problems. 

■  Multiple  Command  and  Control  (C&C)  computer  failures  due  to  task  overrun 
problems.  C&C  computers  failed  to  perform  synehronization  with  GPS  time. 

■  Incorrect  video  cable  harnesses  whieh  would  have  required  difficult  BVA  in  orbit 
to  replace 


“Integrated  Testing  at  KSC  between  Constellation  Systems,”  Tim  Honeycutt, 
Operations  Project  Office,  February  2008. 
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“Integrated  Testing  at  KSC  between  Constellation  Systems,”  Tim  Honeycutt, 
Operations  Project  Office,  February  2008. 
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■  Space  to  ground  communication  audio  was  unacceptable  and  would  have  required 
a  major  on-orbit  upgrade  and  fix. 

The  net  result  of  these  and  other  discoveries  was  a  chance  to  fix  them  while  on  the 
ground  at  significant  cost  and  schedule  saving  as  well  as  a  major  risk  reduction  to  the  crew  and 
to  the  future  missions. 
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MEIT  Configurations 
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Figure  32.  Multi  Element  Integrated  Test  Configurations  for  the  ISS 
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Figure  33.  Multi  Element  Integrated  Test  2  Set  Up  for  the  ISS 
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33.8.2  Software 

The  modules,  experiments  and  ISS  housekeeping  systems  all  had  different  base 
programming  languages  and  were  written  independent  of  each  other  during  development  with 
only  specified  moderately-detailed  interface  specification.  The  issues  tended  to  be  handled 
relatively  well  by  the  IPT  process  and  the  integrations  protocols,  despite  the  lack  of  a  full  rapid¬ 
prototyping  simulation  area  for  the  integrated  software.  The  bigger  issue  was  the  practical 
requirement  for  a  different  and  distinct  software  configuration  for  each  flight  configuration.  This 
required  a  major  systems  engineering  effort  to  coordinate  the  exchange  of  information,  followed 
by  the  process  for  testing  and  assuring  that  changes  were  producing  the  expected  results  for  the 
new  configuration.  Such  multiple-configuration  integration  was  one  of  the  more  important 
aspects  of  the  program  and  the  system  engineering  process. 

Initially,  there  were  over  4  million  lines  of  code  in  the  ISS  command  and  control  system. 
This  code  had  to  accommodate  multi-configurations  to  include  active  modules  for  those  elements 
already  on  orbit  and  “inactive”  software  modules  for  elements  that  had  not  yet  been  delivered. 
As  the  new  ISS  elements  arrived,  the  new  code  was  turned  on.  The  software  test  and  evaluation 
took  place  on  the  ground  using  a  duplicate  of  the  entire  ISS  system  architecture.  This  large 
software  build  has  been  re-written  numerous  times  in  the  ISS’s  lifespan. 

3,4  Execution  Issues 

3,4,1  Unrealistic  Estimates  for  Cost  and  Schedule 

The  ISS  has  one  major  area  in 
common  with  all  current  NASA 
development  programs — significant 
schedule  and  cost  overruns. 

Multiple  GAO  reports  have  targeted 
NASA  for  these  problems  (See 
Figures  34  and  35)^^.  A  recent 
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Aerospace  Corporation  study 
looked  at  a  variety  of  NASA 
programs  and  found  results  typical  to 
those  shown  below  for  forty  NASA 
mission  projects.  The  vast  majority 
all  overran  their  budgets.  The  NASA 
experience  has  been  to  create 
optimistic  schedules  with  the 
majority  suffering  schedule  slippage. 

Starting  with  the  Space 
Station  Freedom  in  the  1990s,  cost 
overruns  on  the  space  station  were  a 

“Perspectives  on  NASA  Mission  Cost  and  Schedule  Performance  Trends,”  David  Beardon,  Presentation  at  GSFC 
Symposium,  June  3,  2008. 
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Figure  34.  NASA  Cost  and  Schedule  Overruns 
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common  problem  and  led  to  its  eventual  redesign.  Despite  excellent  progress  in  technical  areas 
and  in  integrating  its  IPs,  the  program 
suffered  schedule  and  cost  overruns 
from  the  very  start.  By  2001,  the 
problem  was  getting  worse,  so  a  blue- 
ribbon  ISS  Management  and  Cost 
Evaluation  Task  Force  was  created  to 
look  at  the  ISS  program  and  make 
recommendations.^^  This  panel  of 
senior  and  very  experienced  former 
NASA,  government  and  corporate 
experts  delivered  the  following 
findings: 
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Figure  35.  NASA  Schedule  Outcomes 


1.  The  ISS  program  plans  and 
budget  were  not  credible. 

NASA  had  not  and  did  not 
have  the  capability  to  develop 
and  implement  a  rigorous  ISS  cost  estimate.  It  also  did  not  have  the  capability  to  track 
and  audit  costs  in  a  timely  fashion.  NASA  lacked  the  basic  tools  and  financial  staff  to 
create  and  track  a  detailed  life  cycle  cost  estimate. 


2.  The  existing  estimate  at  the  time  (2001)  had  doubled  since  program  inception  and  much 
of  the  cost  and  schedule  growth  was  due  to  poor  original  estimates,  requirements 
definition,  capability  creep,  and  program  changes — all  traditional  reasons  for  cost  growth 
in  large  programs.  [These  issues  were  exacerbated  during  the  Freedom  station  design.  In 
particular,  the  meandering  mission  scope  which  included  stakeholders  for  micro-gravity 
science.  Earth  observation,  satellite  servicing,  and  spacecraft  assembly  for  deep  space 
missions.  Such  diverse  interests  drive  the  system  design  as  well  as  cost  and  schedule 
performance.] 


3.  The  program  was  being  managed  as  an  “institution”  rather  than  a  program  with  specific 
purpose,  focused  goals  and  objectives,  and  defined  milestones.  The  program  budget  was 
paying  for  a  large  number  of  NASA  staff  and  support  contractors — a  “standing  army.” 
This  flat-funding  concept  by  Congress  did  not  match  the  system’s  engineering  life  cycle 
and  prevented  NASA  from  optimizing  the  development  and  construction. 


4.  The  budget  from  Congress  and  NASA’s  focus  on  fiscal  year  management  provided  no 
strategic  management  or  focus.  The  Congress  provided  level  funding,  but  without  multi¬ 
year  authority  to  make  optimal  economic  decisions. 

5.  Fack  of  a  defined  program  created  confusion  and  inefficiencies.  The  budget  and 
execution  did  not  match  reality  and  major  changes  to  the  program  had  been  made 
(reductions)  without  the  approval  of  the  IPs. 


“Report  by  the  International  Space  Station  Management  and  Cost  Evaluation  Task  Force  to  the  NASA  Advisory 
Council,”  November  1,  2001 
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The  result  of  the  budget  growth  and  sehedule  slips  has  been  the  eonstruetion  of  a  station 
with  less  eapability  than  planned  and  with  a  eompletion  date  that  eomplicates  needed  support 
from  all  partners.  After  this  report  was  presented,  the  ISS  suffered  additional  delays  as  a  result 
of  the  Columbia  aeeident. 

3.4,2  Iran,  North  Korea,  and  Syria  Nonproliferation  Act 

The  United  States  uses  trade  ineentives  (or  bans)  as  a  part  of  its  foreign  poliey  to 
eneourage  nations  to  aehieve  its  national  strategies  and  those  of  its  partners.  One  of  the  issues 
that  the  United  States  has  been  coneerned  about  is  the  proliferation  of  nuelear  weapons  and  of 
technologies  for  their  development.  In  the  late  1980s,  the  United  States  and  its  partners  began 
an  effort  to  stop  the  sales  of  ballistic  missile  technology  under  the  Missile  Technology  Control 
Regime  (MTCR).  In  1993,  Russia  joined  the  ISS  partnership  and  agreed  to  abide  by  the 
MTCR  (1995).  During  this  same  period,  it  was  perceived  that  entities  under  the  control  of  the 
Russian  space  Agency  began  to  sell  sensitive  technology  to  Iran.  In  response.  Congress  passed 
the  Iran  Nonproliferation  Act  (INA)  which  banned  the  US  from  doing  business  with  entities 
that  support  Iran — in  this  case,  it  specifically  targeted  the  Russia  Space  industry  and  the  NASA 
human  spaceflight  program.  Prior  to  this,  it  was  estimated  that  the  US  had  spent  $800M  in 
direct  buys  of  goods  and  services  to  support  the  ISS  programs.  However,  the  Iran  Non- 
Proliferation  Act  (INA)  would  put  a  severe  limitation  to  this  unless  Russia  could  demonstrate 
cooperation. 

The  INA  and  its  actual  implementation  in  terms  of  ISS  had  many  restrictions,  but  NASA 
was  still  able  to  move  ahead  with  the  ISS  program.  It  did  not  forbid  the  completion  of  any 
ongoing  contracts  or  agreements.  It  also  allowed  for  the  US  (NASA)  to  purchase  service  if  the 
crew  of  the  ISS  was  in  “imminent”  danger  services  to  maintain  the  existing  Russian  service 
module,  and  $14M  for  Russian  docking  hardware  already  under  development  and  production. 
The  Russian  partnership  agreement  requires  them  to  maintain  a  “lifeboat”  at  the  station  at  all 
times  with  the  capability  to  return  three  astronauts.  Because  it  carries  three,  and  the  Soyuz 
normally  can  stay  aloft  only  six  months,  this  implies  two  launches  per  year.  The  US  must 
provide  the  capability  for  three  more  crew  once  the  station  is  complete  (for  a  total  of  six).  There 
was  also  a  1996  “Balance  Agreement”  to  provide  11  Soyuz  missions  for  Russian  and  American 
(or  other)  crew.  At  this  point,  the  NASA  strategy  was  to  have  either  a  US  crew  rescue  vehicle  in 
place  or  a  new  space  plane.  Neither  of  these  happened  in  the  post  Columbia  environment. 

With  the  new  vision  of  space  exploration  announced  by  the  administration  in  2004,  the 
Space  Shuttle  is  scheduled  for  retirement  in  2010.  NASA  plans  to  contract  for  Soyuz  flights 


***  “The  Iran  Nonproliferation  Act  and  the  International  Space  Station:  Issues  and  Options,”  Sharon  Squassoni  and 
Marcia  S.  Smith.  22  August  2005,  Congressional  Research  Service. 
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The  Missile  Technology  Control  Regime  is  an  informal  and  voluntary  association  of  countries  which  share  the 
goals  of  non-proliferation  of  unmanned  delivery  systems  capable  of  delivering  weapons  of  mass  destruction,  and 
which  seek  to  coordinate  national  export  licensing  efforts  aimed  at  preventing  their  proliferation.  The  MTCR  was 
originally  established  in  1987  by  Canada,  France,  Germany,  Italy,  Japan,  the  United  Kingdom  and  the  United  States. 
Since  that  time,  the  number  of  MTCR  partners  has  increased  to  a  total  of  thirty-four  countries,  all  of  which  have 
equal  standing  within  the  Regime. 

Iran  Nonproliferation  Act,  Public  Law  106-178 
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through  2012  and  for  limited  Progress  flights — ^whieh  should  be  replaeed  by  European,  Japanese 
or  Ameriean  automated  supply  vehicles.  There  remains  an  issue  about  what  happens  after  2012 
and  until  the  new  US  crew  vehicle  is  ready  in  the  2015-2016  timeframe.  Studies  are  underway 
for  human-rating  both  commercial  and  IP  launch  vehicles  that  may  provide  services  to  ISS; 
although  no  decisions  have  been  made  to  enable  US  crew  access  to  ISS  between  2012  and  the 
availability  of  the  Orion/ Ares  1  vehicle. 

3,4.3  ISS  Logistical  Support 

Traditional  crewed  space  vehicles  have  been  designed  for  short  term  missions  with 
maintenance  and  logistics  a  distant  second  to  performance.  The  ISS  challenge  is  more  like 
designing  a  naval  ship  that  operates  in  a  hostile  environment,  but  must  have  periodic 
maintenance  with  no  chance  of  visiting  a  dry  dock.  The  ISS  has  been  in  orbit  as  of  this  writing 
over  4000  days  with  over  nine  full  years  of  crew  habitation.  With  an  expected  lifetime  of  over 
15  years  (2015  and  beyond),  space  logistics  is  a  major  portion  of  the  ISS  program  and  a  learning 
laboratory  for  future  space  exploration  and  engineering. 

As  discussed  previously,  the  transportation  issues  alone  are  complex  and  made  more  so 
by  budget  constraints  and  limitations  on  what  can  be  brought  into  space.  The  system 
engineering  challenge  for  each  system  and  subsystem  had  to  consider  initial  deployment, 
assembly  and  then  possible  repairs  of  all  or  part  of  a  major  component.  To  complicate  this,  the 
designers  also  had  to  consider  spare  parts,  tools,  diagnostic  equipment  and  sensors  (both  ground 
and  on-orbit)  and  how  to  do  maintenance  without  disrupting  the  ISS  operation. 

An  early  discovery  on  the  MIR  by  the  Soviets  was  the  large  amount  of  time  spent  on 
station  maintenance  compared  to  research.  The  ISS  has  been  no  different.  In  the  five-year 
time  period  since  initial  occupation  (2000-2005),  astronauts  spent  over  4000+  hours  on  ISS 
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preventive  and  corrective  maintenance — not  counting  how  long  it  took  to  assemble  the  station. 
This  works  out  to  almost  two  hours  of  maintenance  per  day  per  astronaut. 

One  of  the  challenges  to  system  engineers  when  designing  equipment  and  systems  is 
determining  the  mean-time-between-failures  (MTBF),  which  determines  maintenance  plans  and 
spares  inventory.  Using  traditional  “earth”  values  has  resulted  in  some  ISS  items  far  exceeding 
their  MTBFs — ^which  means  some  of  the  ISS  stored  spares  are  not  needed  and  waste  critical 
space.  If  the  delivered  MTBF  is  too  short,  then  critical  systems  or  services  may  suffer — such  as 
crew  lighting  when  the  bulbs  burn  out  too  soon.  In  most  cases,  the  Orbital  Replacement  Units 
(ORUs)  were  planned  for  removal  and  replacement  on-orbit,  swapped  out  with  spares,  and  the 
failed  equipment  being  shipped  back  to  Earth  for  repair.  Given  the  expected  retirement  of  the 
Space  Shuttle,  this  strategy  for  large  ORU  maintenance  has  shifted  to  storage  of  ORUs  on-orbit. 

A  major  problem  has  been  how  to  deal  with  subsystems  that  fail  in  orbit,  but  which  were 
not  optimized  for  on-orbit  repair  or  replacement.  This  can  be  as  simple  as  lacking  the  right  tool 
for  disassembly  or  the  problem  of  physically  removing  an  item  without  cutting  a  hole  in  the  side 
of  the  ISS.  The  problem  manifests  itself  when  items  on  the  exterior  break  or  fail  and  the  only 
access  is  through  a  space  walk  with  limited  tools  or  ability  to  address  the  system.  The  tools 


“Crew  Maintenance  Lessons  Learned  from  ISS  and  Considerations  for  Future  Manned  Missions,”  Christie 
Bertels,  Senior  Operations  Engineer,  System  Engineering  Support  Services  (SESS),  Munich  Germany  at  the  June 
2006  AIAA  SpaceOps  Conference,  Rome  Italy. 
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themselves  are  an  issue  if  they  have  to  be  ealibrated  or  the  modules  require  different  tools — sueh 
as  metrie  or  standard.  While  there  were  attempts  to  standardize  equipment,  there  are  still 
hundreds  of  different  fasteners,  washers,  ete.  that  all  require  their  own  tools. 

Another  major  issue  is  the  engineering  tradeoff  between  designing  in  automated  health 
monitoring  systems— and  sensors  that  might  pinpoint  failures  to  key  parts— and  how  to  fix 
malfunetioning  equipment  or  major  eomponents.  While  useful,  this  option  inereases 
eomplexity,  eost,  and  weight.  One  major  advantage  that  the  ISS  has  over  other  spaee  systems  is 
the  human  in  the  loop.  On-site  astronauts  tied  in  with  thousands  of  ground  support  engineers 
have  the  ability  to  modify  the  systems  already  in  plaee  plus  innovate  as  needed  with  materials  on 
hand. 

Mundane  issues  have  often  had  major  impaets  in  ISS  operations.  The  use  of  eonsumable 
parts  limits  ISS  funetionality.  A  laek  of  disposable  batteries  and  duet  tape  ean  limit  repairs  or 
researeh  progress.  Items  sueh  as  filters,  earbon  dioxide  serubbers,  water,  eleaners  and  many 
other  items  we  take  for  granted  have  to  be  rationed.  The  design  ehallenge  is  how  to  design  a 
system  where  these  are  not  needed  or  else  minimized. 

A  last  major  issue  mentioned  by  several  of  the  past  ISS  systems  engineers  is 
obsoleseenee  and  shortened  equipment  life-spans.  Some  of  the  major  equipment  is  not  lasting  as 
long  as  NASA  had  hoped  and  the  failure  of  these  parts  and  subsystems  is  foreing  revised 
deeisions  about  upgrades,  replaeement  and  long  term  repair  strategies.  The  rotating  joints  that 
turn  the  large  solar  panels  have  exhibited  failures.  With  the  root  eause  of  the  joint  failure 
unidentified,  the  problem  has  disappeared  with  the  maintenanee  steps  of  eleaning  up  the  filings, 
regreasing  the  joint,  and  installing  the  new  array  (note;  EVAs  performed  in  2008).  Some  of  the 
ISS  systems  eontinue  having  problems — sueh  as  oxygen  generators,  the  new  urine  reeyeling 
system,  and  the  toilets. 

3.4,4  Handling  a  Major  Computer  Failure 

The  importanee  of  the  systems  engineering  proeess  eame  to  light  during  a  major 
eomputer  disruption  that  oeeurred  on  14  June,  2007,  during  the  STS-1 17  mission.  In  this  ease,  it 
shed  light  on  the  requirements,  design,  integration  and  test  and  evaluation  proeess  that  had  been 
used  during  the  ISS’s  early  period  that  resulted  in  the  existing  eonfiguration  of  June  2007. 
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Figure  36.  S TS-1 1 7  Extra-  Vehicular  Activity  at  ISS 

The  major  goal  of  the  STS-1 17  mission  to  the  ISS  was  to  deliver  and  deploy  the  last  major  set  of 
large  solar  arrays  (See  Figure  36).  Each  ISS  solar  wing  contains  two  115  foot  long  panels  that 
attach  to  a  central  truss  for  a  total  width  of  almost  240  feet  and  a  weight  of  17.5  tons.  Unfurling 
the  panels  is  a  slow,  tedious  procedure  that  has  not  always  gone  as  planned.  On  a  previous 
assembly  mission  (STS-97),  a  similar  panel  failed  to  deploy  properly  and  had  to  be  repaired 
during  a  subsequent  space  walk.  This  deployment  went  smoothly — considering  the  120-foot 
panel  had  been  in  storage  for  several  years,  compressed  into  a  block  only  20-inches  deep  (see 
Figure  37).  In  order  to  provide  a  clear  field  of  view  for  the  new  panels,  an  older  solar  array  had 
to  be  furled  and  stowed.  Both  the  new  and  old 
panels  generate  several  KWs  of  power,  create 
large  static  charges  and  can  generate  radio  and 
static  noise. 

The  first  hint  of  trouble  came  during 
the  deployment  when  the  Russian  navigation 
computer  developed  some  anomalies  forcing 
the  ISS  crew  to  switch  to  the  Space  Shuttle 
Atlantis’s  thrusters  along  with  the  ISS  US 
gyroscopes  to  maintain  attitude  control.  This 
delayed  the  initial  power  up  of  the  solar  wings 
(since  the  ISS  was  not  initially  in  optimal 

position  to  charge  the  panels)  Figures?,  stowed  Solar  Panel  Being  UnfoUed  for  Deployment 


“Engineers  Close  in  on  Cause  of  ISS  Computer  Glitch,”  Tariq  Mailik,  Space  News.  23  July  2007. 
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A  short  time  later  on  14  July,  all  six  of  the  command  and  control  computers  in  the 
Russian  module  failed.  The  computers  controlled  the  Russian  module  attitude  control  thrusters 
as  well  as  the  Elektron  oxygen  generators  and  other  atmosphere  control  system  equipment.  The 
station  did  have  sufficient  oxygen  on  board  for  the  short  run  (estimated  at  56  days  for  the  basic 
ISS  crew),  but  this  would  have  long-term  impacts  if  unresolved.  To  control  the  station,  the  ISS 
used  the  four  US  control  moment  gyroscopes  to  maintain  orientation  along  with  the  Space 
Shuttle  Atlantis  thrusters.  The  computers  also  controlled  power  to  the  Soyuz  return  vehicle 
(lifeboat)  and  the  external  service  module  cooling  loops.  The  atmospheric  control  system  and 
carbon  dioxide  scrubbers  were  also  offline.  As  a  result,  the  station  internal  temperature  began  to 
rise.  After  two  of  the  computers  were  rebooted,  this  triggered  a  false  alarm  for  the  crew  in  the 
middle  of  a  sleep  cycle. 

The  computers  were  eventually  brought  back  on  line  by  running  jumper  cables  to  bypass 
the  computers  power  monitoring  devices.  After  running  tests  of  all  critical  systems,  the  Shuttle 
Atlantis  departed  with  replacement  computers  to  be  delivered  on  board  an  unmanned  Russian 
supply  ship  (Progress).  While  the  fix  seemed  to  work,  it  was  not  immediately  clear  why  it 
worked. 

This  was  not  the  first  command  and  control  computer  system  failure — in  2001  the  mass 

storage  drives  on  the  US  side  had  suffered  a  failure  and  had  to  be  replaced.  Again  in  February 

2002,  the  main  computer  shut  down  for  several  hours  before  the  crew  and  ground  controllers 

were  able  to  reboot  it.  It  was  however,  the  first  major  failure  of  all  three,  redundant  computer 

systems.  The  Russian  computers  were  developed  and  manufactured  by  Daimler  Benz  (German 

company)  almost  a  decade  before.  The  initial  starting  point  for  a  solution  was  to  determine  what 

might  have  triggered  the  event  (root  cause  analysis).  The  astronauts  had  just  connected  the  new 

truss  elements  a  few  minutes  before  the  failure  sequence  began.  Both  the  Russians  and  NASA 

were  aware  that  the  ISS  electrical  properties  can  change  with  each  new  configuration.  It  was 

known  that  the  Russian  computer  system  design  was  sensitive  to  static  noise  and  voltage  spikes  - 

thus  the  need  for  a  sophisticated  power  monitoring  system.  With  the  addition  of  a  major  solar 

array  and  the  movement  of  an  existing  one,  it  appeared  that  this  was  an  obvious  source  of  a  static 

or  electrical  spike  that  might  cause  a  computer  failure.  The  US  modules  used  a  structural  ground 

system  while  the  Russians  used  a  floating  ground  approach.  Adding  a  major  new  module  or 
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element  could  cause  a  potential  difference  between  the  Russian  ground  and  the  ISS  structure. 
The  basic  theory  at  the  time  was  that  the  electrically  charged  plasma  field  shifted  when  the  ISS’s 
shape  changed  with  the  addition  of  the  new  truss  and  solar  panels.  Both  NASA  and  the 
Russian  space  companies  alluded  to  this  as  a  probable  cause — and  both  proved  to  be  premature 
and  wrong. 


“International  Systems  Integration  on  the  International  Space  Station,”  William  H.  Gerstenmaier,  Ronald  L. 
Ticker,  IAC-07-B3-1.01 

NASA  International  Space  Station  Status  Report  #01-13,9  May  2001 
International  Space  Station  Status  Report,  #02-07 
**  “Legacy  of  the  ISS  Computer  Crisis,”  Spaceflight  Magazine.  2008  January. 

“ISS  Computer  Woes  Concern  Europe,”  Irene  Klotz,  BBC  News,  June  2007. 

“Space  Station  Repairs  on  Main  Computer  System  Continues,”  Todd  Weiss,  Computer  World.  15  June  2007. 
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After  the  Atlantis  left,  the  ISS  crew  (Russians  Fyodor  Yurchikhin  and  Oleg  Kotov  and 
American  Clayton  Anderson)  disassembled  the  individual  systems  to  troubleshoot  possible 
causes.  They  suspected  the  power  monitoring  system  since  the  bypass  around  it  allowed  the 
computers  to  work  (though  it  did  present  a  risk  to  possible  voltage  spikes).  While  disassembling 
the  power  monitoring  systems  they  discovered  connection  pins  that  were  corroded  and  wet. 
Performing  continuity  checks,  they  discovered  that  one  of  the  main  lines  had  shorted  out.  More 
surprising,  when  they  and  ground  personnel  simulated  the  failure  of  the  lines,  they  discovered 
that  this  created  a  power  off  command  to  all  three  of  the  “redundant”  processing  units — they  had 
a  single  point  failure  designed  into  the  system. 

A  Russian  Progress  26P  re-supply  ship  was  launched  on  2  Aug  2007  to  bring  supplies 
and  replacement  computers  (new  models  built  by  ESA).  On  August  8,  the  Endeavor  launched 
with  STS-1 18  crew  to  install  another  major  truss  segment  and  to  continue  work  on  the  computer 
system.  Eurther  investigation  by  the  crew  found  the  source  of  the  corrosion — water 
condensation.  They  determined  that  the  units  were  close  to  dehumidifiers  that  mal-functioned, 
ejecting  water  vapor  on  the  unit.  When  the  boxes  were  removed  for  replacement,  their  bases 
were  wet  and  mold  was  discovered. 

The  good  news  for  the  ISS  was  that  the  computers  did  not  have  a  fatal  flaw.  The  same 
computer  system  was  built  into  the  European  Columbus  Eaboratory  Module  that  was  scheduled 
to  fly  later  in  2008.  They  also  were  on  the  Automated  Transport  Vehicle  scheduled  for  2008 
launch.  Replacing  and  or  redesigning  that  system  would  have  been  a  major  problem  for  both 
systems. 

In  retrospect,  this  incident  focused  questions  on  key  areas  of  the  systems  engineering 
process: 

1 .  Did  the  requirements  and  integration  process  encompass  all  needed  areas? 

a.  Grounding  issues  and  electrical  impacts  of  configurations  changes 

b.  Impacts  of  humidity  on  electronics  and  the  adequacy  of  the  environmental 
control  system 

c.  Systems  integration  between  international  systems 

2.  Was  the  test  and  evaluation  process  sufficient? 

a.  How  did  the  German/Russian  system  contain  a  single  point  failure  node? 

b.  How  are  configuration  changes  modeled,  studied  and  tested? 

c.  Were  the  computers/electronics  properly  tested  for  the  ISS  environment? 

3.4,5  Transportation 

Transportation  to  the  ISS  is  a  major  part  of  the  system  that  is  equal  in  importance  to  the 
safety  and  reliability  of  the  ISS  itself  The  US  Skylab  experience  is  a  painful  reminder  that  a 
failure  to  integrate  the  schedule,  budget  and  planning  of  a  new  system  with  all  critical  elements 
can  lead  to  unwanted  outcomes.  In  the  case  of  Skylab,  the  system  was  totally  dependent  on  the 
old  Apollo  systems  for  initial  launch  and  servicing,  and  then  the  promised  availability  of  the 
shuttle  for  continued  operation  and  support.  In  hindsight,  it  appeared  questionable  why  the  US 
would  launch  a  system  that  could  be  used  for  only  one  year  (1973-74),  cancel  the  existing 
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transportation  system  (Apollo),  and  then  expeet  to  park  it  in  orbit  for  at  least  five  years  (until  late 
1978)  on  the  hope  that  the  Space  Shuttle  would  be  on  schedule  and  capable  of  immediately 
performing  maintenance  missions.  This  obviously  demonstrates  the  challenge  inherent  in  US 
plans  to  retire  the  Shuttle  in  the  2010  timeframe  with  a  known  gap  in  US  crew  transport  to 
service  the  ISS.^'  This  is  a  basic  systems  engineering  requirements  discussion  coupled  with 
budget  and  politics.  However,  the  benefits  of  international  partnership  highlights  the  fact  that 
even  if  the  US  is  unable  to  sustain  the  ISS,  the  robust  partnership  is  in  place  to  sustain  it. 

3.4. 5.1  Impacts  of  launch  delays  (Columbia  failure) 

From  the  beginning  of  the  ISS  program,  the 
space  shuttle  fleet  was  considered  an  essential  part  of 
the  ISS  program  and  critical  to  its  completion.  The 
Space  Shuttle  (Figure  38)  is  the  only  vehicle  capable  of 
carrying  large  payloads  of  up  to  36,000  lbs  into  low 
earth  orbit.  The  remaining  ISS  major  modules  were 
designed  to  be  carried  on  the  shuttle.  The  shuttle  also 
transports  the  multi-purpose  logistics  module  to  the  ISS 
which  is  loaded  with  cargo,  supplies,  experiments  and 
other  key  life  support  items.  It  is  removed  from  the 
cargo  bay  and  docked  with  the  ISS  for  unloading.  At 
the  end  of  the  mission,  it  is  loaded  with  trash,  waste 
material  and  experiments  and  placed  in  the  shuttle  bay 
for  return  to  earth. 

Throughout  the  program,  the  schedule  has  always  been  optimistic  and  included  little 
slack  to  accommodate  risk.  At  a  very  top  level,  much  of  the  program  cost  is  for  the  “standing 
army”  of  scientists,  engineers  and  technicians  that  work  for  NASA,  its  partners,  and  its 
contractors.  For  the  Shuttle  this  is  the  large  team  required  to  process  the  vehicle  for  flight.  For 
the  ISS  the  significant  problem  is  the  extended  development  time  that  requires  maintaining  the 
team  at  a  higher  staffing  level.  As  the  program  slips  for  a  variety  of  reasons,  this  “fixed  yearly 
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cost”  continues  and  raises  the  total  program  cost.  Several  major  government  and  NASA  panels 
have  studied  these  issues  and  recommended  major  program  changes  to  reduce  cost — most  of 
which  also  reduced  the  final  size  or  capability  of  the  ISS  and  the  number  of  shuttle  flights. 

When  the  shuttle  Columbia  was  lost  in  February  2003,  NASA  grounded  all  remaining 
shuttles  indefinitely  pending  the  outcome  of  the  accident  investigation.  This  meant  a  day  for  day 
slip  in  the  ISS  construction  schedule,  plus  a  serious  problem  on  how  to  logistically  support  the 
station  and  transport  astronauts.  The  Russians  already  were  providing  Soyuz  and  Progress 
flights  carrying  six  astronauts  per  year  plus  cargo.  Initially,  many  options  were  contemplated, 
including  bringing  the  Americans  home  from  the  ISS.  The  inventories  of  food  and  supplies  were 
carefully  updated  and  tracked  closely  on  orbit  and  on  the  ground  to  determine  the  feasibility  of 
continuing  ISS  operations  relying  solely  on  Russian  capability.  A  strategy  eventually  developed 


“The  Vision  for  US  Space  Exploration,”  NASA  Report,  February  2004 

“Report  by  the  International  Space  Station  Management  and  Cost  Evaluation  Task  Force  to  the  NASA  Advisory 
Council^  NASA  Report,  1  Nov  2001. 
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that  reduced  the  crew  aboard  ISS  from  three  to  two — one  Russian  and  one  American — and 
officially  lengthened  the  Increment  duration  from  approximately  4  months  to  a  standard  6 
months  to  fit  the  Soyuz  rotation  schedule.  Upon  completion  of  Increment  6,  the  ISS  complement 
was  reduced  to  two  people.  This  situation  was  managed  as  a  temporary  situation,  although  it 
eventually  lasted  two  and  a  half  years. 

The  grounding  of  the  Shuttle  fleet  lasted  until  July  of  2005  (almost  30  months)  with  the 
launch  of  the  shuttle  Discovery.  It  was  then  another  year  (July  2006),  before  the  next  shuttle 
visited  the  ISS.  This  caused  a  number  of  impacts  to  the  ISS  program: 

■  The  number  of  Progress  vehicles  was  increased  to  3-4  per  year  to  provide 
logistics  support.  This  required  a  modification  to  the  exemption  of  the  Iran,  North 
Korea  and  Syria  Nonproliferation  Act. 

■  Shuttle  payloads  already  packed  and  certified  had  to  be  unpacked  and  the  contents 
safely  stored.  Some  of  the  contents  and  equipment  had  to  be  serviced,  and  in 
some  cases  replaced  due  to  their  time  sensitive  natures  (such  as  batteries  and 
fluids) 

■  A  solar  array  awaiting  launch  had  to  be  unpacked  and  unfurled  and  then 
recertified.  Another  solar  array  wing  had  to  be  returned  to  the  factory  and 
replaced  since  it  was  only  allowed  to  be  in  storage  (tightly  packed  in  its  container) 
for  a  fixed  period  of  time. 

■  The  single  most  significant  impact  was  the  reduction  of  crew  size  for  several 
expeditions  from  3  to  2.  This  was  done  largely  to  improve  margins  on  critical 
logistics. 

■  Obviously,  only  limited  repairs  could  be  made  on  the  ISS  without  spare  parts  or 
new  equipment.  Without  new  research  and  or  maintenance  equipment,  the  ISS 
crew  used  the  existing  resources  more — which  contributed  to  higher  failure  rates. 
Very  limited  equipment  was  flown  on  Progress  and  Soyuz. 

■  A  normal  part  of  every  shuttle  mission  was  the  return  of  science  experiments, 
especially  time  sensitive  experiments.  The  Soyuz  vehicle  had  very  little  space  to 
return  payloads;  so  much  of  this  research  was  not  completed. 

While  the  total  cost  of  the  delay  may  never  be  known,  it  was  significant.  NASA 
estimated  that  the  following  were  the  major  issues  they  faced  that  drove  cost: 

■  The  30-month  delay  before  resuming  normal  flight  schedules  extended  the  cost  of 
maintaining  the  ISS  support  staff  and  contractors  to  finish  development 

■  Numerous  requirements  to  recertify  equipment 

■  Disassembly,  reassembly  and  in  some  case  repair  of  component  parts 

■  Cost  of  additional  storage 

■  Cost  of  maintaining  and  replacing  consumables  (especially  batteries) 

■  Storage  effects  on  the  solar  arrays 


“Impact  of  the  Grounding  of  the  Shuttle  Fleet,:  GAO  Report  GAO-03-1 107,  September  2003. 
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■  Additional  cost  of  Russia  support  flights  and  the  cost  of  travel  and  working  with 
Russians 

■  Continued  cost  of  maintaining  critical  engineering  skills  on  the  program  for  an 
additional  30-40  months. 


3.4. 5.2  Russian  Soyuz  and  Progress  vehicles 

From  the  start  of  the  ISS  program,  it  was  assumed  that  there  would  be  serviee  and 
transportation  missions  eonsisting  of  the  US  Spaee  Shuttle,  Soviet  expendable  vehieles  (Soyuz 
and  Progress)  along  with  future  systems  to  be  developed.  The  Russians  had  extensive 
experience  with  their  early  space  stations  through  the  more  reeent  Mir  program  with  launching 
cargo  and  cosmonauts.  They  developed  very  reliable  automated  docking  capability  that  allowed 
them  to  routinely  use  unmanned  Progress  resupply  vehieles. 

For  crewed  transportation,  the  Russians  have  used  their  Soyuz  systems  sueeessfully  16 
times  carrying  47  astronauts  up  to  the  ISS  and  returning  48  astronauts  to  Russia.  However, 
recent  return  missions  in  the  Soyuz  have  raised  some  fears  about  the  safety  of  the  Russian 
system.  On  21  October  2007,  Soyuz  TMA-10  undoeked  from  the  ISS  for  an  expeeted,  normal 
return  earrying  two  eosmonauts  and  a  space  flight  partieipant  (paying  passenger).  Normally,  the 
utility  module  is  detaehed  and  sent  in  a  safe  direetion  to  de-orbit  and  bum  up.  The  propulsion  or 
instmment  assembly  module  is  bolted  to  the  bottom  and  provides  the  required  de-orbit  bum  to 
slow  the  spaceeraft  and  align  it  for  reentry  (See  Figure  39).  Onee  on  course,  the  propulsion 
module’s  explosive  attaehment  bolts  fire  and  the  two  are  separated.  The  eapsule  then  begins  its 
reentry  in  a  heat  shield  down  mode  where  it  “skims”  along  the  atmosphere  from  the  lift 
generated  which  limits  the  heat  buildup  and  limits  the  G-force  on  the  astronauts  to  a  4.5  G 
maximum. 


Ullllly  module 


landing  module 


InstiumenI-  assembly 
module 


Figure  39.  Soyuz  Manned  Vehicle 


In  this  case,  the  eapsule  failed  to  properly  separate  from  the  propulsion  module 
(apparently  due  to  a  eontrol  eable  issue)  and  was  not  able  to  fly  the  normal  trajectory.  Instead, 
after  the  propulsion  module  separated,  the  eapsule  went  into  a  fail-safe  mode  and  took  a  steep, 
ballistic  trajectory.  This  subjected  the  crew  to  almost  9  Gs  plus  generated  signifieant  bum 
damage  to  the  eapsule’s  exterior. 
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Figure  40.  Fire  at  Scene  of  Soyuz  Capsule  Landing 


The  capsule  landed  hard,  several  hundred  kilometers  off  course,  and  was  so  hot  it  started 
a  grass  fire  around  the  capsule  (see  Figure  40).  One  of  the  cosmonauts  reported  later  that  the 
grass  fire  burned  quite  heavily  causing  smoke  to  enter  the  ventilation  system  of  the  capsule 
(normally  opens  upon  landing)  causing  the  three  cosmonauts  to  switch  back  to  their  spacesuit 
breathing  modes. 

Six  months  later  (April  2008),  a  similar  incident  occurred.  This  time  Soyuz  TMA-11 
was  returning  one  American  (ISS  Commander  Peggy  Whitson),  a  Korean  and  a  Russian 
astronaut  when  the  capsule  failed  to  properly  separate.  This  time  the  culprit  was  thought  to  be 
faulty  explosive  separation  bolt.  Once  again,  when  the  normal  systems  failed,  the  capsule 
defaulted  to  the  fail-safe  mode  and  performed  a  ballistic  trajectory  subjecting  the  astronauts  to  a 
high  G  reentry.  The  Korean  astronaut  suffered  back  injuries  as  a  result  of  the  hard  landing. 

As  a  result  of  these  two  incidents,  two  Russian  cosmonauts  on  the  ISS  made  a  spacewalk 
in  July  2008  to  remove  one  of  the  explosive  bolts  from  the  Soyuz  TMA-12  that  was  docked  and 
planned  for  an  upcoming  descent.  That  Soyuz  did  successfully  return  with  a  near  perfect  landing 
in  October  2008  with  two  cosmonauts  and  an  American  tourist. 

The  Progress  supply  ship  has  an  excellent  record  with  over  thirty-seven  missions  to  the 
ISS.  Compared  to  the  Soyuz,  it  does  not  have  to  safely  reenter  the  atmosphere  and  land — instead 
it  is  normally  filled  with  waste  and  sent  on  a  trajectory  to  bum  up  in  the  atmosphere.  NASA  has 
decided  to  stop  using  Progress  after  2011  in  favor  of  promised  US-based  commercial  launch 
providers.  Several  firms  are  competing  for  contracts  to  provide  logistics  support  to  the  ISS  in  the 
post  2010  time  frame.  (See  section  3.2.6) 

This  policy  decision  to  not  spend  money  on  Russian  vehicles  and  instead  invest  the 
money  in  American  technology  made  good  domestic  public  policy  sense.  However,  from  a 
systems  engineering  risk  viewpoint,  it  must  take  into  account  the  TRL  levels  of  the  replacement 
systems,  the  cost,  the  schedule,  the  risk  and  the  relevant  MTBF  of  the  new  systems.  As  an 
example,  one  of  the  US  competitors  is  Space  Exploration  Technologies  Falcon  1  rocket  (See 


“Space  Crews  Hard  Landing  Raises  Hard  Questions,”  James  Oberg,  MSNBC  News. 
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Figure  41).  It  completed  its  first  successful 
launch  on  28  September  2008  after  three 
previous  failures  and  plans  on  delivering  1000 
kg  payloads  to  low  earth  orbit  for  about  $10M. 

3.4. 5.3  Retirement  of  the  Shuttle 

Two  key  parts  of  any  well-engineered 
system  of  systems  are  that  all  parts  work  well 
with  each  other  (integration  and  performance) 
and  that  the  various  systems  are  available  when 
needed.  In  the  case  of  the  ISS  and  the  Shuttle, 
the  Shuttle  was  always  destined  to  be  a  key 
element  of  the  successful  construction  and  station  operation. 

In  later  testimony  to  Congress, the  Administrator  explained  that  the  decision  to  retire 
the  Space  Shuttle  is  basically  one  of  trading  off  the  ISS  (and  its  completion)  against  future 
manned  spaceflight  capability  if  it  requires  extending  the  Shuttle  beyond  2010; 

“Retirement  of  the  Space  Shuttle  is  on  schedule  for  2010  and  critical  to  future 
Exploration  plans.  As  we  approach  this  date,  we  are  hopeful  that  we  can  complete 
the  ten  remaining  Space  Station  assembly  flights,  the  servicing  mission  to  the 
Hubble  Space  Telescope,  and  the  two  contingency  Shuttle  missions  to  the  ISS 
within  this  timeframe.  If  it  becomes  clear  that  we  will  not  complete  the  flight 
manifest  by  2010,  NASA  will  evaluate  options  and  make  adjustments  consistent 
with  not  flying  any  flights  beyond  2010.  Continuing  to  fly  the  Shuttle  beyond  2010 
does  not  enhance  U.S.  human  spaceflight  capability,  but  rather  delays  the  time 
until  a  new  capability  exists  and  increases  the  total  life  cycle  cost  to  bring  the  new 
capability  on  line.  .  .  .  Flying  the  Space  Shuttle  past  2010  would  carry  significant 
risks,  particularly  to  our  efforts  to  build  and  purchase  new  transportation  systems 
that  are  less  complex,  less  expensive  to  operate,  and  better  suited  to  serving  both 
ISS  utilization  and  exploration  missions  to  the  Moon,  Mars,  and  beyond.  ” 

The  decision  to  retire  the  shuttle  has  been  controversial.  From  a  systems  engineering 
viewpoint,  the  decision  should  consider  risk,  cost,  safety  and  performance  to  decide  what  the 
best  overall  approach  should  be.  Further,  with  a  significant  downward  trend  in  the  economy 
NASA  programs  are  not  at  the  top  of  Congressional  priorities,  and  are  thus  vulnerable,  especially 
when  already  winding  down.  Such  a  budgetary  position  tends  to  lead  to  “status  quo”  in 
congressional  direction:  the  sense  that  NASA  should  plod  on  with  the  existing  year’s  mode  of 
business  until  directed  otherwise.  In  this  backdrop  of  political  and  financial  reality,  George  W. 
Bush’s  vision  for  NASA  in  February  2004  required  the  shutting-down  of  two  existing  programs 
with  expensive  but  functioning  infrastructure,  with  ongoing  missions  that  had  been  actively 
cultured  as  priorities  with  the  American  public  and  with  many  international  partners.  Once  the 
“keep  on  operating”  status  quo  was  replaced  with  a  “keep  on  shutting  down,  and  waiting  for  the 
next  big  thing”  status  quo,  NASA  was  deeply  limited  and  constrained  in  its  ISS  systems 


Statement  of  Administrator  Michael  Griffin  to  the  Subcommittee  on  Space,  Aeronautics  and  Related  Sciences,  15 
November  2007 
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engineering  options.  While  the  shuttle  program’s  realities  were  of  course  more  dire  than  ISS’s 
with  their  more  immediate  shut-down,  the  ISS  also  faced  a  highly  uncertain  and  less  desirable 
future  than  the  one  for  which  it  had  been  designed.  The  entire  ISS  maintenance  strategy  had  to 
be  re-engineered  for  a  slow  obsolescence  with  no  chance  of  major  Shuttle  repair  flights  or 
ground  refurbishment  of  critical  large  system  components.  The  logistics  and  crew  rotations 
would  be  severely  cut  back  from  original  plans.  Meanwhile,  the  inevitable  delays  in  the  Orion 
spacecraft  have  led  to  a  long  forecast  period  of  no  US  launch  capability,  significantly  dulling  the 
accustomed  luster  of  the  US  Space  program  on  the  world  stage. 

The  Shuttle  has  been  the  primary  transportation  for  long  duration  US  crew  members  and 
for  short  term  US  research,  construction  and  visits  by  US  astronauts.  If  the  Shuttle  is  terminated 
after  2010,  the  US  will  be  dependent  on  the  Russians  for  crew  transportation  until  a  domestic 
capability  is  ready.  Initial  analysis  done  by  NASA  indicates  a  gross  requirement  for  sustainment 
supplies  of  80  metric  tonnes  (MT)  between  2010  and  2015.  Additionally,  the  plan  is  to  occupy 
the  ISS  with  a  full  time  crew  of  six,  with  each  crew  doing  six  month  rotations.  Of  the  six  person 
crew,  three  would  be  Russian  and  three  would  be  from  the  US,  Canada,  Europe  or  Japan.  The 
US  has  current  arrangements  with  the  Russians  for  crew  launches  (Soyuz)  through  2011  only  and 
for  limited  Progress  flights. 

Sustaining  the  International  Partnership 

A  major  question  for  the  US  and  its  partners  is  how  well  the  international  partnership  has 
worked  and  what  may  be  useful  on  future  cooperative  ventures.  There  is  little  doubt  that  the 
participation  by  the  IPs  allowed  the  program  to  succeed  much  more  quickly  and  more 
successfully  than  if  the  US  had  shouldered  the  entire  program.  In  fact,  the  dissimilar  redundancy 
in  launch  capability  ensured  the  continuation  of  the  program  through  the  Columbia  accident 
down  time. 

■  Despite  the  different  systems  engineering  environments,  the  IPs  were  able  to  work 
with  the  joint  SE  structure  and  integrate  modules  and  systems  that  came  from 
very  different  development  processes. 

■  It  is  quite  possible  that  Congress  and/or  a  US  President  would  have  cancelled  the 

Q7 

program  had  not  an  IP  arrangement  occurred  to  execute  the  new  ISS  design. 

Q8 

Prom  our  partner’s  viewpoints,  there  were  some  major  challenges: 

■  The  Japanese  invested  heavily  in  the  program  early  on  and  met  their  original 
schedules  only  to  face  months  and  years  of  wait  times  prior  to  launch  and/or  on 
orbit  participation. 


As  a  reference  point,  in  2005,  NASA  paid  Russia  $43. 8M  for  one  seat  up  to  the  ISS  and  one  seat  down  using  the 
Soyuz  vehicle. 

In  January  1993,  the  first  advice  given  to  the  new  President  Clinton  by  his  Budget  Director  Leon  Panetta  was  to 
cancel  the  Space  Station.  Lawmakers  Guide  to  Balancing  the  Federal  Budget.  June  9,  1992. 

“Foreign  Policy  in  Orbit:  The  International  Space  Station,”  John  M.  Logsdon,  Director,  Space  Policy  Institute, 
George  Washington  University’s  Elliot  School  of  International  Affairs. 
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■  The  Russians  were  essentially  on  sehedule  to  deliver  the  first  module  (Funetional 
Cargo  Bloek — FOB)  as  it  was  funded  by  the  US.  Their  next  major  module, 
Zvezda,  was  almost  two  years  late,  primarily  due  to  Russian  funding  issues. 

■  ESA  and  CSA  have  all  remained  in  the  program,  but  like  all  IPs,  their  level  of 
financial  support  has  varied  and  is  often  a  function  of  domestic  politics. 

3,4,6  Anomaly  Resolution  and  the  Columbia  Accident 

A  major  issue  that  has  challenged  NASA  and  other  managers  of  major  programs  is  how 
to  handle  technical  and  or  performance  anomalies  that  occur.  This  has  been  at  the  heart  of  the 
two  Shuttle  accidents  and  at  incidents  related  to  the  ISS  and  other  NASA  programs.  This 
involves  the  proper  identification,  reporting,  investigation,  resolution  and  documentation  for  all 
ISS  crew,  hardware  and  software  issues.  At  issue  is  how  to  have  the  full  resources  of  NASA 
(and  the  international  team)  quickly  focus  on  and  solve  a  problem  before  the  ISS  and  its  crew  are 
placed  in  peril — while  at  the  same  time  not  declaring  an  emergency  with  every  possible  incident 
and  making  the  operation  of  the  ISS  impossible.  Following  the  Columbia  accident,  NASA 
reviewed  its  policies  to  include  anomaly  resolution  for  the  ISS.^^  The  main  recommendations 
(October  2003)  that  affected  the  ISS  were  as  follows: 

■  The  ISS  will  provide  capability  to  do  external  surveys  of  visiting  spacecraft  as 
well  as  itself  ISS  external  surveys  of  itself  (to  discover  damage  or  maintenance 
issues)  are  limited  in  certain  areas  without  Shuttle  support.  The  ISS  and  crew 
since  that  time  have  completed  surveys  and  developed  procedures  for  regular 
inspections. 

■  The  board  directed  the  ISS  team  to  review  all  of  its  analytical  models  that  are 
used  to  support  on-orbit  operations,  anomaly  resolution  and  decision  making 
processes. 

■  Evaluate  and  improve  ISS  shielding  and  planning  to  avoid  damage  from 
micrometeoroid  or  orbital  debris  damage.  This  has  taken  the  form  of  additional 
shielding,  movement  of  the  station  and  new  procedures  and  equipment  to  handle 
possible  impact  damage. 

■  The  report  directed  the  ISS  team  to  address  major  nonconformance  report  issues. 
The  most  serious  was  that  the  Space  Shuttle  reaction  jet  drive  system  did  not  have 
adequate  failure  tolerance  to  control  against  an  inadvertent  firing  when  attached  to 
the  ISS.  This  was  fixed. 

■  While  not  a  hardware  issue,  one  of  the  most  important  recommendations  was  a 
major  review  and  validation  of  the  ISS  anomaly  resolution  process  and  its  work 
instructions,  to  assure  that  proper  resources  were  assigned  and  processes  were 
begun  in  a  timely  manner  to  deal  with  anomalies  early. 


“NASA’s  Implementation  Plan  for  International  Space  Station  Continuing  Flight, ’’October  28,  2003.  This  was 
the  ISS  Program’s  response  to  the  Columbia  Accident  Investigation  Board’s  Report. 
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3,4.7  Major  Risks  to  the  ISS 

As  part  of  the  SE  process,  NASA  and  its  international  partners  have  had  to  carefully 
consider  all  design  elements  and  requirements.  A  key  consideration  is  the  remoteness  of  the  ISS 
relative  to  traditional  systems  and  the  inability  to  rapidly  provide  additional  support  (i.e.,  quickly 
supply  spare  parts  or  personnel  onsite).  The  most  likely  operational  safety  risks  are  briefly 
discussed  below  along  with  their  demonstrated  or  planned  solutions. 

■  Micrometeoroid  and  Orbital  Debris  (MMOD)  Damage: There  are  millions  of 
particles  in  orbit  that  range  from  micro-millimeter  sized  particles  to  large  pieces 
of  decaying  spacecraft.  While  most  large  pieces  are  tracked,  there  is  always  a 
probability  of  impact.  For  the  larger  tracked  items,  the  ISS  can  be  moved  given 
enough  warning.  The  ISS  is  designed  with  a  level  of  protection  in  its  outer  skin 
for  most  modules.  MMOD  debris  panels  have  been  added  to  protect  the  Russian 
modules  and  the  living  quarters.  There  is  also  the  danger  of  impact  during 
extravehicular  activities,  as  the  space  suits  have  a  lesser  level  of  protection.  The 
probabilities  of  MMOD  impacts  have  been  studied  to  show  how  safety  is 
improved  with  service  module  augmentations  in  place  and  additional  Russian 
Progress  and  Soyuz  enhancements: 

Table  3.  Probability  of  Penetration  Damage  to  the  ISS 


Existing  ISS  Design 

With  Service  Module 
Augmentations  in 
Place 

With  Service  Module 
Augmentations  plus 
Progress  and  Soyuz 
Enhancements 

No  Penetration 

45% 

54% 

71% 

Isolate  the 

Penetrated 

Element 

19% 

16% 

11% 

Penetration 
Leading  to  ISS 
Abandonment 

18% 

14% 

8% 

Repairable 

Penetration 

9% 

8% 

5% 

Penetration 
Leading  to  Loss 
of  ISS  and/or 

crew 

9% 

8% 

5% 

As  the  table  indicates,  there  is  a  very  good  chance  that  the  ISS  will  sustain  some  level 
of  appreciable  damage  during  its  lifetime. 


A  further  discussion  on  micrometeorite  and  orbital  debris  protection  is  at  3.3.7. 
****  SM  stands  for  service  module 
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■  Collision  with  vehicles  or  remote  manipulator  systems:  The  MIR  program 
demonstrated  that  collisions  between  the  various  vehicles  and  the  ISS  are  a  real 
possibility.  A  major  engineering  challenge  of  the  ISS  was  how  to  unload  cargo 
and  personnel  from  arriving  space  vehicles  and  how  to  move  the  new  or  old 
module  around  for  installation.  Arriving  vehicles  all  have  a  combination  of 
automated  and  manual  docking  interfaces  and  procedures.  These  vehicles  use  a 
three-tiered  approach  to  ensure  safety: 

1.  The  vehicles  must  have  at  least  a  two-failure  tolerant  approach  against 
catastrophic  outcomes.  The  system  must  have  onboard  fault  detection, 
isolation  and  reconfiguration  capability  plus  the  ability  to  self  monitor  all 
critical  functions.  It  must  have  an  independent  collision  avoidance  maneuver 
function.  There  must  be  a  manual  ground  and  crew  monitoring  capability  to 
follow  progress  and  react  to  out  of  tolerance  situations.  It  must  have 
robustness  against  failed  capture  capabilities. 

2.  The  second  level  of  protection  requires  that  the  ground  station  be  able  to 
monitor  all  aspects  of  the  activity  with  the  ability  to  abort  while  the  ISS  crew 
must  be  able  to  monitor  and  take  evasive  actions. 

3.  The  third  level  of  protection  requires  the  new  systems  to  demonstrate  key 
capabilities  during  their  first  flight  while  maintaining  a  safe  distance  from  the 
ISS  prior  to  an  actual  attempted  docking. 

■  There  is  also  a  risk  of  damage  from  any  of  the  space  station’s  robotic  arms.  In 
some  case,  there  are  definite  limits  to  their  movement  that  prevent  damage. 
However,  most  have  to  have  the  ability  to  reach  most  areas  of  the  ISS  to  be 
useful.  The  key  approaches  to  safety  for  these  operations  center  on  two-fault 
tolerant  designs,  extensive  crew  training,  monitoring  by  the  crew  and  the  ground 
support  and  careful  mission  design  and  simulation. 

■  Fire:  This  is  a  major  hazard  and  the  primary  safety  approach  is  prevention.  In  the 
early  design  phase,  the  engineers  carefully  selected  fire-safe  materials  and 
mechanical/electrical  designs  with  low  probability  of  fire  creation.  There  is  also 
extensive  fire  detection  (smoke  and  heat  alarms)  throughout  the  ISS  to  provide 
quick  warning  of  any  dangerous  situations.  The  ISS  system  was  designed  to 
identify  the  fire  site,  isolate  the  area  (remove  power,  ventilation  and  oxygen),  and 
extinguish  the  source  without  damaging  the  station  or  endangering  the  crew.  The 
physics  of  a  fire  in  space  make  this  a  very  unlikely  but  still  dangerous  possibility. 
A  chronic  problem  early  in  the  program  was  that  the  very  sensitive  smoke 
detectors  (particularly  those  in  the  FGB)  would  too  often  alarm  ground  operators 
and  crew  at  nuisance  levels.  Although  there  have  been  dozens  of  alarms,  not  a 
single  actual  fire  has  occurred  onboard.  The  ISS  is  also  equipped  with  hand-held 
fire  extinguishers  and  the  crew  is  trained  in  their  use. 


The  MIR  was  hit  on  at  least  two  separate  occasions,  once  with  a  Progress  transfer  vehicle  and  another  with  a 
Soyuz.  The  Progress  accident  caused  a  module  to  depressurize. 
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■  Toxic  Spills:  The  main  means  of  preventing  toxic  spills  is  by  not  bringing  toxic 
materials  on  board  or  containing  them  in  spill-proof  deviees.  When  toxic  items 
are  allowed,  the  crew  follows  strict  procedures  for  using  the  items  and  eondueting 
the  experiments  or  procedures.  The  crew  has  well-praeticed  proeedures  for 
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cleaning  spills  in  microgravity  and  has  access  to  full  protective  gear  if  needed. 

■  Catastrophic  system  failure:  This  type  of  failure  and  its  prevention  permeate  the 
SE  approach  to  the  ISS.  At  eaeh  stage  of  review,  methods  for  reducing  this  risk 
are  considered — redundaney,  sound  design  specifieation,  rigorous  testing,  and 
risk  assessment.  After  the  Columbia  accident,  the  ISS  management  team  took  the 
opportunity  to  foeus  on  the  ISS  to  see  if  any  significant  risk  remained.  If  found, 
these  are  documented  in  noneomplianee  reports  (NCR).  The  only  signifieant 
NCR  remaining  at  this  time  dealt  with  the  shuttle  reaetion  jet  driver  (RJD)  and 
primary  jet  thrusters.  The  danger  was  that  they  might  inadvertently  fire  and 
damage  the  ISS.  NASA  quickly  studied  the  issue  and  dictated  no  fire  zones 
during  certain  key  operations,  performing  avionics  checks  prior  to  system 
activation,  and  performing  each  flight’s  first-time  Shuttle  equipment  power-up 
before  Shuttle  doeking  to  the  ISS. 

■  Extravehicular  Activity  (EVA):  This  is  primarily  the  safety  of  the  astronauts,  their 
equipment  and  the  contamination  of  their  equipment  and  danger  of  damaging  the 
exterior  of  the  ISS.  The  most  important  preventative  measure  has  been  the 
extensive  planning  and  practiee  of  the  EVAs.  Eaeh  EVA  has  been  rehearsed 
underwater  (when  possible)  for  hundreds  of  hours  prior  to  the  missions  to  ensure 
the  astronauts  understand  the  repair,  have  the  right  tools,  and  have  the  EVAs 
orehestrated  properly  using  the  robotic  arms  if  needed.  There  is  also  an  intra- 
vehicular  crew  member  always  coordinating  with  the  EVA  crew.  The  biggest 
danger  to  date  has  been  a  concern  about  damaging  the  suits.  This  can  happen  due 
to  a  rip  or  tear,  ehemical  exposure  or  eontamination  or  puneture  by  a  meteorite  or 
orbital  debris.  The  suits  are  a  compromise  between  flexibility  and  impact 
protection.  The  eurrent  EVA  requirement  for  MMOD  is  to  meet  a  probability  of 
no  penetration  of  91%  against  two  member  performing  2700  hours  of  EVAs. 
Current  analysis  puts  the  actual  probability  at  94%.  So  far,  there  has  been  no 
evidenee  of  a  MMOD  impact  to  any  of  the  EVA  suits. 

■  There  is  a  danger  of  contamination  from  ISS  materials  and  lubricants.  On  a 
recent  mission  (18  November  2008)  an  astronaut  was  preparing  to  repair  and 
lubricate  one  of  the  solar  array  joints. In  a  pre-packed  tool  kit,  the  astronaut 
opened  the  bag  and  diseovered  one  of  the  grease  cartridges  for  the  grease  gun  had 
“exploded,”  contaminating  everything  in  the  bag — along  with  the  astronaut’s 


On  19  Sept  2006,  the  first  ever  “emergency”  was  declared  on  the  ISS  when  a  Russian  oxygen  generator 
(Elekton)  malfunctioned  and  began  to  overheat.  It  caused  an  o-ring  to  overheat  and  smoke,  which  allowed  some 
potassium  hydroxide  to  leak.  The  three  astronauts  quickly  donned  protective  gas  masks  and  implemented  their 
emergency  procedures  to  isolate  the  module  and  the  spill.  They  cleaned  up  the  spill  with  towels  and  used  special 
carbon  filters  to  scrub  the  air.  Within  a  few  hours,  the  station  air  was  clean  again  and  the  situation  was  over. 
(Associated  Press  Report,  Seth  Borenstein,  19  Sept  2006) 

“Engineers  Study  Options  for  Replacing  Lost  Grease  guns,”  William  Harwood,  CBS  News,  18  Nov  2008 
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gloves  and  sleeves.  The  cleanup  method  was  to  basically  wipe  up  the  grease  with 
towels  and  store  the  dirty  towel  and  most  of  the  grease  in  plastic  pouches.  In  this 
case,  the  problem  is  more  than  just  a  minor  mess;  the  remaining  grease  on  the 
space  suit  can  contaminate  the  airlock,  the  space  station  interior  and  exterior — to 
include  sensors  and  exterior  experiment  payloads. 

■  Errant  Commands  or  Security  Compromises:  The  ISS  by  design  shares  a  great 
deal  of  control  with  the  ground  stations.  There  is  always  a  danger  of  an  outside 
source  compromising  the  security  and  sending  false  commands.  The  ISS  design 
and  operation  meet  all  NASA  and  National  Security  Agency  (NSA)  requirements. 
The  systems  are  tested  and  challenged  regularly  to  maintain  system  security. 
There  is  also  a  risk  of  an  inadvertent  critical  command  from  NASA.  Commands 
that  could  cause  catastrophic  damage  are  required  to  be  two-stage  commands — a 
separate  “arm”  and  then  “fire.”  Additionally,  these  types  of  commands  are 
automatically  safed  and  require  approval  by  Mission  Control  Center  personnel  at 
Houston  and  must  also  be  approved  by  the  mission  flight  director.  There  is  also 
software  protection  on  other  critical  commands  that  query  the  crew  with  “are  you 
sure”  messages  that  must  be  acknowledged.  NASA  reports  that  each  year,  over 
100,000  commands  are  sent  to  the  station  with  a  command  accuracy  exceeding 
99.95%. 

3,5  Long  Term  Outlook 

The  long-term  challenges  for  the  ISS  are  more  financial  and  political  in  nature  than 
systems  engineering  problems.  The  United  States,  like  its  IPs,  is  facing  economic  pressures 
during  a  down  economy  while  trying  to  develop  a  new  crewed  launch  system  (see  Figure  42)  and 
a  new  exploration  program  to  the  moon  and  beyond  (dubbed  the  Constellation  Program).  As 
discussed  earlier,  the  US  decision  to  retire  the  shuttle  has  had  major  impacts  on  the  ISS 
completion  and  operation.  The  US  has  also  discussed  possible  retirement  dates  for  the  ISS  and 
what  that  would  mean  to  its  partners.  Many  of  the  partners  invested  and  developed  their 
modules  with  the  plan  of  a  long  station  life  on  orbit.  Many,  including  the  Russians,  are  even 
considering  possible  new  additions  to  the  ISS  for  research.  The  possibility  of  an  early  shut 
down  of  the  ISS  would  have  negative  impacts  on  future  cooperative  efforts. 

In  May  2009  the  station's  crew  was  expanded  from  three  to  six  astronauts,  A  record  39 
Russian  space  launches  were  planned  for  2009,  as  opposed  to  27  in  2008  (not  all  to  ISS,  but  an 
indicator  of  the  robustness  of  the  Russian  program,  even  in  light  of  the  world’s  financial  crisis). 

While  the  Constellation  Program  competes  for  budget  with  the  legacy  ISS  program,  it 
also  may  become  the  biggest  supporter  and  benefactor  of  the  ISS.^*^^  During  the  development 
phase  of  the  new  program,  it  will  have  to  do  a  capabilities-based  assessment  of  planned 
technologies.  Many  of  these  new  or  modified  technologies  will  be  needed  for  long  duration 
space  missions  and  will  require  extensive  validation.  While  some  tests  are  quite  feasible  on  the 


105  “'pjjg  Role  of  Space  Stations  in  Russia’s  Long  Term  Exploration  Strategy,”  Valery  Borisov  and  Audrey 
Golovinken,  IBC  Workshop,  Berlin,  November  17,  2006. 

“Reduction  of  Space  Exploration  Risk — Use  of  ISS  as  a  Test  Bed  for  Enabling  Technologies,”  Ilia  Rosenberg, 
Michael  Clifford,  and  Joy  Bryant,  The  Boeing  Company,  AIAA  conference  paper. 
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ground,  the  best  method  is  to  test  them  in  the  environment  in  whieh  they  will  operate — outer 
spaee.  The  ISS  as  a  test  bed  for  space  exploration  is  the  best  tool  to  evaluate  the  acceptable 
tradeoff  between  new  technology,  manufacturing  maturity  and  applicability  for  long  duration 
spaceflights. 

Despite  political  and  financial  challenges,  there  are  some  indications  that  the  ISS  may 

1  AT 

already  be  suffering  premature  aging  issues  that  could  shorten  its  lifespan.  In  January  2009, 
ISS  rockets  were  commanded  to  fire  to  move  the  station  into  a  higher  orbit  as  part  of  routine 
station-keeping.  An  incorrect  delay  filter  was  loaded  for  the  “off  pulsing”  delta-V  bum,  allowing 
the  jet  pulses  to  hit  a  resonance  with  fundamental  ISS  stmctural  modes.  The  jet  firing  filter  is 
designed  to  prevent  just  such  an  occurrence,  and  the  resonant  excitation  had  the  potential  to 
severely  limit  the  fatigue  life  of  the  ISS,  which  diminishes  roughly  as  the  fourth  power  of  the 
magnitude  of  the  applied  load.  This  load  reached  previously  unexpected  levels  during  the 
incident.  Onboard  video  confirmed  that  the  station  shook  severely — much  like  a  ship  in  a  violent 
storm.  The  vibration  episode  was  severe  enough  that  the  three  astronauts  notified  mission 
control  and  ground  engineers  did  a  full  check  of  the  station’s  systems.  While  nothing  was  found 
to  be  wrong,  ground  controllers  delayed  additional  thmster  bums  for  two  months  to  give  them 
time  to  recheck  the  systems.  NASA  Space  Station  program  manager  Mike  Suffredini  noted  that 
while  this  event  appears  not  to  have  harmed  the  station,  its  total  lifetime  has  been  shortened  due 
to  extra  stress  on  its  components  over  the  years. 


***’  “Nasa  Delays  Shuttle  Launch,  Space  Station’s  Relocation,”  Traci  Watson,  USA  Today,  February  4,  2009. 
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Figure  42.  Orion  Visiting  the  ISS 


4.0  SUMMARY 

4,1  Summary 

The  International  Space  Station  definitely  has  been  the  most  complex  NASA  systems 
engineering  program  to  date.  Despite  the  enormous  challenge  of  dealing  with  International 
Partners,  multiple  configurations  and  a  dynamic  political  environment,  the  ISS  is  close  to 
completing  its  final  configuration  and  becoming  fully  operational.  A  major  element  of  its 
success  has  been  the  program  management  and  effective  systems  engineering  process  that  NASA 
has  developed  and  executed  over  the  last  three  decades. 

The  success  of  the  ISS  traces  back  to  the  original  decisions  to  use  much  of  the 
demonstrated  technologies  from  the  Skylab,  Space  Station  Freedom,  Shuttle  missions  and 
eventually,  the  Russian  contributions  that  were  proven  onboard  MIR  and  it  predecessors.  While 
many  of  the  systems  were  updated,  it  was  done  in  an  evolutionary  manner  that  reduced  system 
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risk,  reduced  cost  and  minimized  schedule  risk.  Another  major  part  of  the  success  was  the  team 
effort  to  develop  advanced  element-to-element  physical  and  functional  verification  methods  for 
interfaces  assembled  on-orbit.  While  this  was  also  applied  at  the  sub-system  level,  this  helped  to 
discover  and  quickly  fix  many  system  problems  that  would  have  been  very  difficult,  if  not 
impossible  to  fix  once  on  orbit.  Finally,  NASA  and  its  partners  developed  an  excellent  systems 
engineering  approach  to  handle  the  40+  on-orbit  configurations  that  placed  demanding 
requirements  on  unique  software,  hardware  and  operational  requirements  every  time  the  ISS  was 
upgraded  with  the  next  component  or  modules.  Such  evolutionary  performance  is  atypical  of 
almost  every  other  complex  electromechanical  system,  and  its  complexity  is  compounded  by  the 
additional  strict  requirements  of  human-rated  space  hardware. 

NASA  and  its  partners  also  had  problems  that  the  system  engineering  approach  had  to 
either  deal  with  or  work  around.  The  biggest  issue  was  program  uncertainty  from  all  the 
countries  as  budgets  were  adjusted  or  eliminated  during  the  life  of  the  program.  The  current  plan 
for  the  Shuttle  retirement  and  the  uncertain  lifespan  of  the  ISS  (prior  to  decommissioning) 
remains  a  major  issue  for  the  ISS  partners. 

4,2  Lessons  Learned 

We  interviewed  experts  and  asked  what  they  felt  were  the  most  important  lessons  learned 
for  NASA  systems  engineers.  While  there  were  a  variety  of  responses,  those  responses  tended  to 
repeat  the  same  core  topics  discussed  below: 

■  Sometimes  difficult  topics  need  to  be  finessed  with  the  use  of  less-than-precise  language. 
While  open  to  interpretation  or  requiring  future  interpretation,  such  constructive  ambiguity 

1  AO 

allows  negotiators  to  move  beyond  an  impasse. 

■  Don’t  be  so  ready  to  chase  revolutionary  designs  over  evolutionary  designs.  A  key  lesson 
from  Russian  experience  (such  as  the  Soyuz)  is  that  it  is  often  less  risky  to  stay  with  a  known 
design  and  provide  minor  improvements. 

■  Multi-Element  Integrated  Testing  with  actual  hardware,  high  fidelity  simulators  and 
connectors  is  critical  and  must  be  in  the  program  from  day  one. 

■  Systems  engineering  involves  communications,  critical  to  international  partnerships,  so 
before  worrying  about  technical  interfaces,  make  sure  the  integrated  product  teams  and 
communication  bandwidth  between  partners  are  optimal.  This  fundamentally  includes  face- 
to-face  meetings,  so  regular  international  travel  is  a  large  and  essential  part  of  the  systems 
engineering  cost. 

■  In  an  ISS  like  project  where  so  many  different  countries  and  companies  contribute  hardware 
and  software,  the  interfaces  must  be  extremely  simple. 

■  Maintaining  a  high  level  of  competent  and  experienced  personnel  over  a  two  decade  long 
program  requires  strategic  level  planning  and  execution  of  workforce  planning.  Despite 
budget  realities,  cyclical  hiring  and  layoffs  due  to  budget  minimized  workforce  competence. 

■  Don’t  be  too  quick  to  allow  partners  (or  NASA)  to  start  building  modules  or  expensive 
experiments  too  far  in  advance  of  locking  in  schedule  and  program  baseline. 


****  “Structuring  Future  International  Cooperation:  Learning  from  the  ISS,”  L.  Cline,  P.  Finarelli,  G.  Gibbs,  I.  Pryke, 
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■  Conversely,  physically  simple  models  are  important,  especially  in  the  early  systems 
engineering  phase.  These  should  be  budgeted  for  and  provided  on  a  continuing  basis.  A 
simple  turned-wood  model  can  be  produced  overnight  to  illustrate  most  of  the  complex 
geometries  of  a  typical  spacecraft,  and  such  a  model  definitely  beats  using  lay-around  objects 
such  as  pencils  and  salt  shakers  to  imitate  construction  or  rendezvous  details.  Generally, 
appropriate  crude  models  were  scarce,  with  the  Program  waiting  for  the  next  design  iteration 
before  commissioning  an  official  one-of-a-kind  public  relations  model.  Such  lower-fidelity 
models  were  most  needed  by  the  engineers  during  the  process  to  get  to  that  next  iteration. 
Some  of  the  most  rapid  gains  in  the  US  integration  with  Russian  partners  occurred  with  crude 
models  cut  from  cardboard  and  wood  during  breaks  between  meetings.  (One  team  even  built 
a  full-scale  cardboard  mockup  of  a  key  US-Russian  interface  along  their  meeting  table  during 
a  week-long  meeting,  and  filled  in  many  interface  control  details  using  a  tape  measure 
against  the  model). 


This  is  not  unique  to  the  ISS.  NASA  previously  built  a  back-up  Skylab  that  was  not  used  and  today  hangs  in  the 
Smithsonian  as  one  of  the  most  expensive  exhibits.  The  Russian  Multi-Purpose  Logistic  Module  is  another 
example  of  major  hardware  that  was  started,  then  stopped,  then  started  again  and  finally  launched  into  space. 


88 


APPENDICES 


89 


APPENDIX  1.  AUTHOR  BIOGRAPHIES 


DR.  WILLIAM  K.  STOCKMAN,  LT.  COL,  USAF  (RET) 

Dr.  William  Stockman  is  currently  a  Senior  Associate  at  Dayton 
Aerospace,  Inc.  and  an  Adjunct  Professor  at  the  Air  Force  Institute  of 
Technology.  He  has  30  years  experience  in  the  areas  of  engineering, 
acquisition  management  and  strategy,  economics,  cost  estimating,  graduate 
and  undergraduate  education,  and  acquisition  research.  He  authored  two 
recent  AFIT  case  studies,  JASSM  and  Peacekeeper. 

Ft.  Colonel  Stockman  retired  from  the  USAF  in  2002  as  Deputy 
Department  Head  and  Graduate  Cost  Degree  Chairman,  Department  of 
Systems  and  Engineering  Management,  Air  Force  Institute  of  Technology,  WPAFB,  OH.  Prior 
to  that,  he  held  positions  as  Executive  Secretary  and  lead  analyst  at  the  OSD  CAIG,  Mathematics 
Instructor  at  the  US  Air  Force  Academy,  Director  of  Depot  Maintenance  Cost  Analysis  for  the 
Assistant  Secretary  of  the  Air  Force  and  a  Propulsion  Engineer  at  the  Air  Force  Rocket 
Propulsion  Laboratory,  Edwards  AFB,  CA. 

Dr.  Stockman  received  a  BS  in  Mathematics  and  a  BS  in  Business  Administration  in 
1977  from  Southeast  Missouri  University,  a  BS  in  Aeronautical  Engineering  in  1984  from  AFIT, 
a  MS  in  Engineering  Management  in  1986  from  West  Coast  University,  an  MS  in  Operations 
Research  in  1988  from  AFIT,  an  MA  in  Economics  in  1995  from  George  Mason  University  and 
a  PhD  in  Economics  in  1996  from  George  Mason  University. 


JOSEPH  F.  BOYLE,  COE,  USAF  (RET) 

Joseph  Boyle  is  a  seasoned  program  manager,  researcher,  space 
professional  and  engineer  with  28  years  hands-on  experience  successfully 
managing  and  guiding  hardware  and  software  intensive  development, 
production  and  support  programs — in  the  USAF,  Joint,  and  International 
arenas.  He  served  as  Deputy  System  Program  Director  for  the  Evolved 
Expendable  Launch  Vehicle.  He  has  assisted  numerous  industry  and 
government  organizations  structuring  complex  program  execution  plans. 

Mr.  Boyle  received  a  BS  in  Mechanical  Engineering  from  Norwich  University  and  a  MS, 
in  Systems  Management  from  the  University  of  Southern  California.  He  also  is  a  graduate  of  the 
DOD  Program  Manager’s  Course  from  the  Defense  Systems  Management  College  and  from  the 
USAF  Air  Command  and  Staff  College. 

John  B,  Bacon,  Ph.D, 

Dr.  Bacon  is  currently  a  systems  analyst  working  on  numerous  integration  assignments 
affecting  the  International  Space  Station,  within  the  ISS  Program  Integration  office  at  the  NASA 
Johnson  Space  Center  in  Houston.  A  veteran  NASA  engineer  since  1990,  he  has  worked  in  all 
aspects  of  ISS  technology  and  systems,  and  with  all  the  ISS  international  partners.  A  graduate  of 


90 


Caltech  (B.S.  76)  and  of  the  University  of  Rochester  (MS  ’78,  Ph.D.  ’84)  his  extensive  career 
prior  to  NASA  includes  roles  in  the  development  of  many  cutting  edge  technologies,  including 
controlled  thermonuclear  fusion,  the  development  of  the  electronic  office,  factory  automation, 
and  the  globalization  of  business.  He  pioneered  the  deployment  of  several  artificial  intelligence 
systems. 

He  was  the  United  States'  lead  systems  integrator  of  the  Zarya— the  jointly-built 
spacecraft  that  forms  the  central  bridge  and  adapter  between  all  US  and  Russian  technologies  on 
the  Space  Station.  This  landmark  in  technological  history  was  built  in  Moscow  by  American  and 
Russian  engineers  and  launched  from  the  Baikonur  Cosmodrome  in  November  1998. 

Among  his  numerous  awards,  he  is  a  recipient  of  NASA’s  Exceptional  Achievement 
Medal,  the  Director’s  Special  Commendation,  and  the  coveted  Silver  Snoopy  award-the  only 
award  to  fly  in  space.  He  routinely  advises  numerous  academic  programs  and  institutions,  and 
he  is  a  champion  of  education  throughout  the  world. 


91 


APPENDIX  2,  ACRONYMS 


IP  Progress  flight*'*^ 

IS  Soyuz  flight 
AC  Assembly  Complete 
ACU  Arm  Control  Unit 
ARC  Ames  Researeh  Center 
ARIS  Active  Rack  Isolation  System 
ATCS  Active  Thermal  Control  System 
atm  Atmospheres 

ATV  Automated  Transfer  Vehicle,  launched 
by  Ariane  [ESA] 

ATV-CC  Automated  Transfer 
VehicleControl  Centre 

BCA  Battery  Charging  Assembly 

BCDU  Battery  Charge  Discharge  Unit 

BSA  Battery  Stowage  Assembly 

CBM  Common  Berthing  Mechanism 

CC  Control  Center 

CCAA  Common  Cabin  Air  Assembly 

CCC  Contaminant  Control  Cartridge 

CDRA  Carbon  Dioxide  Removal  Assembly 

CETA  Crew  and  Equipment 
TranslationAid/ Assembly 

CEV  Crew  Exploration  Vehicle 

CEVIS  Cycle  Ergometer  with  Vibration 
Isolation  System 

CHeCS  Crew  Health  Care  System 
CMG  Control  Moment  Gyroscope 
CMRS  Crew  Medical  Restraint  System 


NASA  Space  Flight  Guide 


CMS  Countermeasures  System 

CNES  Centre  National  D’Etudes  Spatiales 
[Erench  space  agency] 

COE  Columbus  Orbital  Eacility 

COL-CC  Columbus  Control  Centre 

COTS  Commercial  Orbital 

Transportation  Services 

CPDS  Charged  Particle  Directional 
Spectrometer 

CRPCM  Canadian  Remote  Power 

Controller  Module 

CSA  Canadian  Space  Agency 

CTB  Cargo  Transfer  Bag 

CWC  Contingency  Water  Container 

DC  Docking  Compartment;  Direct  Current 

DCSU  Direct  Current  Switching  Unit 

DDCU  DC-to-DC  Converter  Unit 

DDT«&E  Design,  Development,  Test,  and 
Evaluation 

DLR  German  Aerospace  Center 

DMS  Data  Management  System 

DOS  Eong-Duration  Orbital  Station 
[Russian] 

EADS  European  Aeronautic  Defence  and 
Space  Company 

ECLSS  Environmental  Control  and  Eife 
Support  System 

ECS  Exercise  Countermeasures  System 
ECU  Electronics  Control  Unit 
EDR  European  Drawer  Rack 
EDV  Water  Storage  Container  [Russian] 
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EF  Exposed  Facility 

EHS  Environmental  Health  System 

EEC  Expres  Eogistics  Carrier 

ELM  Experiment  Eogistics  Module 

EMU  Extravehicular  Mobility  Unit 

EPM  European  Physiology  Module 

EPS  Electrical  Power  System 

ERA  European  Robotic  Arm 

ESA  European  Space  Agency 

ESTEC  European  Space  Research  and 
Technology  Centre 

ETC  European  Transport  Carrier 

EVA  Extravehicular  Activity 

ExPCA  EXPRESS  Carrier  Avionics 

EXPRESS  Expedite  the  Processing  of 
Experiments  to  the  Space  Station 

FGB  Functional  Cargo  Block 

FRAM  Flight  Releasable  Attachment 
Mechanism 

FRGF  Flight  Releasable  Grapple  Fixture 

ESA  Roscosmos,  Russian  Federal  Space 
Agency 

FSL  Fluid  Science  Eaboratory 

GASMAP  Gas  Analyzer  System  for 
Metabolic  Analysis  Physiology 

GB  Gigabyte 

GCM  Gas  Calibration  Module 

GCTC  Gagarin  Cosmonaut  Training  Center 

GN&C  Guidance,  Navigation,  and  Control 

GLONASS  Global  Navigation  Satellite 
System  [Russian] 

GPS  Global  Positioning  System 

GRC  Glenn  Research  Center 

GSC  Guiana  Space  Center 


HMS  Health  Maintenance  System 

HRF  Human  Research  Facility 

HTV  H-II  Transfer  Vehicle  [JAXA] 

IBMP  Institute  for  Biomedical  Problems 

ICC  Integrated  Cargo  Carrier 

ICS  Internal  Communications  System 

lEA  Integrated  Equipment  Assembly 

IRU  In-flight  Refill  Unit 

ISPR  International  Standard  Payload  Rack 

ISS  International  Space  Station 

ITA  Integrated  Truss  Assembly 

ITS  Integrated  Truss  Structure 

IV-CPDS  Intravehicular  Charged  Particle 
Directional  Spectrometer 

JAXA  Japan  Aerospace  Exploration  Agency 

JEM  Japanese  Experiment  Module 

JEM-ELM  Japanese  Experiment  Module- 
Experiment  Eogistics  Module 

JEM-ELM-EF  Japanese  Experiment 
Module-Experiment  Eogistics  Module- 
Exposed  Facility 

JEM-ELM-ES  Japanese  Experiment 
Module-Experiment  Eogistics  Module- 
Exposed  Section 

JEM-ELM-PS  Japanese  Experiment 
Module-Experiment  Eogistics  Module- 
Pressurized  Section 

JEM-PM  Japanese  Experiment  Module- 
Pressurized  Module 

JEM-RMS  Japanese  Experiment  Module- 
Remote  Manipulator  System 

JSC  Johnson  Space  Center 

kgf  Kilogram  Force 

kN  Kilonewton 

KSC  Kennedy  Space  Center 

Ibf  Pound  Force 
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LF  Logistics  Flight 
LiOH  Lithium  Hydroxide 
LSS  Life  Support  Subsystem 
Mb  Megabit 

MBS  Mobile  Base  System 

MBSU  Main  Bus  Switching  Unit 

MCC  Mission  Control  Center 

MDM  Multiplexer-Demultiplexer 

MELFI  Minus  Eighty-Degree  Laboratory 
Freezer  for  ISS 

MGBX  Microgravity  Science  Glovebox 

MLE  Middeek  Locker  Equivalent 

MEM  Multipurpose  Eaboratory  Module 

MMOD  Mierometeoroid/Orbital  Debris 

MMU  Mass  Memory  Unit 

MOC  MSS  Operations  Complex 

MPLM  Multi-Purpose  Eogistics  Module 

MSEC  Marshall  Spaee  Flight  Center 

MSS  Mobile  Servieing  System 

MX  Mobile  Transporter 

NASA  National  Aeronauties  and  Spaee 
Administration 

NAVSTAR  Navigation  Signal  Timing  and 
Ranging  [U.S.  satellite] 

NPO  Production  Enterprise  [Russian] 

NTO  Nitrogen  Tetroxide 

NTSC  National  Television  Standards 
Committee 

OMS  Orbital  Maneuvering  System 
OGS  Oxygen  Generation  System 
ORU  Orbital  Replacement  Unit 
OVC  Oxygen  Ventilation  Circuit 
PI,  P6,  etc.  Port  trusses 
PCAS  Passive  Common  Attach  System 


PDA  Payload  Disconneet  Assembly 

PDGF  Payload  Data  Grapple  Fixture 

PLSS  Primary  Fife  Support  System 

PM  Pressurized  Module 

PMA  Pressurized  Mating  Adapter 

POC  Payload  Operations  Center;  Primary 
Oxygen  Circuit 

PROX  OPS  Proximity  Operations 

PSA  Power  Supply  Assembly 

PSC  Physiological  Signal  Conditioner 

PTCS  Passive  Thermal  Control  System 

PVGF  Power  Video  Grapple  Fixture 

PVR  Photovoltaie  Radiator 

RED  Resistive  Exereise  Deviee 

RGA  Rate  Gyro  Assembly 

RM  Research  Module 

RMS  Remote  Manipulation,  Manipulator 
System 

RPC  Remote  Power  Controller 

rpm  Revolutions  Per  Minute 

ROEU-PDA  Remotely  Operated  Eleetrical 
Umbilical-Power  Distribution  Assembly 

RPCM  Remote  Power  Controller  Module 

RSC  Roeket  and  Space  Corporation 

RV  Reentry  Vehicle 

S«&M  Structures  and  Meehanisms 

SO  or  S  Zero,  Starboard  trusses 

SI,  etc, 

SARJ  Solar  (Array)  Alpha  Rotation  Joint 
SAFER  Simplihed  Aid  for  EVA  Rescue 
SASA  S-Band  Antenna  Struetural  Assembly 
SAW  Solar  Array  Wing 
SFOG  Solid  Fuel  Oxygen  Generator 
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SFP  Space  Flight  Participant 

SCANT  Space-to-Ground  Antenna 

SM  Service  Module 

SPDM  Special  Purpose  Dexterous 
Manipulator 

SS  Spaee  Shuttle 

SSA  Spaee  Suit  Assembly 

SSIPC  Spaee  Station  Integration  and 
Promotion  Center 

SSRMS  Spaee  Station  Remote  Manipulator 
System 

SSU  Sequential  Shunt  Unit 

STS  Space  Transportation  System 

TCS  Thermal  Control  System 

TDRS  Tracking  and  Data  Relay  Satellite 

TEPC  Tissue  Equivalent  Proportional 
Counter 

TKS  Orbital  Transfer  System 

TKSC  Tsukuba  Space  Center 

TMA  Transportation  Modified 
Anthropometric 


TMG  Thermal  Mierometeoroid  Garment 

TNSC  Tanegashima  Space  Center 

TORU  Progress  Remote  Control  Unit 
[Russian] 

TSC  Telescience  Support  Center 

TSS  Temporary  Sleep  Station 

TSUP  Moscow  Mission  Control 

TVIS  Treadmill  Vibration  Isolation  System 

UDMH  Unsymmetrical  Dimethylhydrazine 

UF  Utilization  Flight 

UHF  Ultra-High  Frequency 

ULF  Utilization  and  Fogistics  Flight 

UMA  Umbilical  Mating  Assembly 

USOC  User  Support  and  Operations  Centre 

VDC  Voltage,  Direct  Current 

VDU  Video  Distribution  Unit 

VO  A  Volatile  Organie  Analyzer 

WRS  Water  Recovery  System 

Z1  Zenith  1,  a  truss  segment 
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APPENDIX  3.  SPACELAB  MISSIONS 


•  STS-9,  Spacelab  1,  November  1983,  Module  LMl  and  Pallet  {Columbia) 

•  STS-51-B,  Spaeelab  3,  April  1985,  Module  LMl  {Challenger) 

•  STS-51-F,  Spaeelab  2,  July  1985,  triple  Pallet  eonfiguration  {Challenger) 

•  STS-61-A,  Spaeelab  Dl,  Oetober  1985,  Module  LM2  {Challenger) 

•  STS-35,  ASTRO-1,  Deeember  1990,  Pallet  {Columbia) 

•  STS-40,  SLS-1,  June  1991,  Module  LMl  {Columbia) 

•  STS-42,  lML-1,  January  1992,  Module  LM2  {Discovery) 

•  STS-45,  ATLAS-1,  Mareh  1992,  double  Pallet  configuration  {Atlantis) 

.  STS-50,  USML-1,  June  1992,  Module  LMl  {Columbia) 

•  STS-47,  Spacelab-J,  September  1992,  Module  LM2  {Endeavour) 

•  STS-56,  ATLAS-2,  April  1993,  Pallet  {Discovery) 

•  STS-55,  Spacelab  D2,  April  1993,  Module  LMl  {Columbia) 

•  STS-58,  SLS-2,  October  1993,  Module  LM2  {Columbia) 

•  STS-59,  SRL-1,  April  1994,  Pallet  {Endeavour) 

.  STS-65,  lML-2,  July  1994,  Module  LMl  {Columbia) 

•  STS-68,  SRL-2,  October  1994,  Pallet  {Endeavour) 

•  STS-66,  ATLAS-3,  November  1994,  Pallet  {Atlantis) 

•  STS-67,  ASTRO-2,  March  1995,  Pallet  {Endeavour) 

•  STS-71,  Spacelab-Mir,  June  1995,  Module  LM2  {Atlantis) 

.  STS-73,  USML-2,  October  1995,  Module  LMl  {Columbia) 

•  STS-78,  LMS,  June  1996,  Module  LM2  {Columbia) 

.  STS-83,  MSL-1,  April  1997,  Module  LMl  {Columbia) 

.  STS-94,  MSL-1  R,  July  1997,  Module  LMl  {Columbia) 

•  STS-90,  Neurolab,  April  1998,  Module  LM2  {Columbia) 

•  STS-99,  SRTM,  February  2000,  Pallet  {Endeavour) 


96 


APPENDIX  4.  PHASE  ONE— SHUTTLE-MIR  MISSIONS 


1994  - 

Feb  STS-60:  First  Cosmonaut  on  the  Shuttle 

3-11  Sergei  K.  Krikalev  was  the  first  Cosmonaut  to  fiy  aboard  the  Shuttle. 

1995  - 

Feb  STS-63:  First  Rendezvous  with  Mir 

3-11  With  Cosmonaut  VladiMir  Titov  aboard,  Discovery  rendezvoused  with  Mir, 
closed  to  within  37  feet,  and  performed  a  fly-around,  but  did  not  dock. 

Mar  14  Thagard  Increment:  First  Astronaut  on  Mir 

-  Jul  7  Astronaut  Norman  Thagard  launched  with  Cosmonauts  VladiMir  Dezhurov  and 

Gennady  Strekalov  aboard  a  Russian  Soyuz  to  spend  115  days  on  Mir. 

Jun  27  STS-71:  First  Docking 

-  Jul  7  Atlantis  performed  the  first  shuttle  docking  with  Mir;  delivered  a  replacement 

crew  —  cosmonauts  Anatoly  Solovyev  and  Nikolai  Budarin  —  and  returned 
Dezhurov,  Strekalov,  and  Thagard  to  Earth. 

Nov  STS-74:  A  New  Docking  Module 

12  -  20  The  first  shuttle  assembly  flight  to  Mir,  it  carried  a  Russian-built,  U.S. -funded 
docking  module  with  two  attached  solar  arrays. 

1996  - 

Mar  STS-76:  Starting  a  Continuous  U.S.  Presence 

22-31  This  mission  carried  Shannon  Lucid  to  Mir,  demonstrated  logistics  capabilities 
with  a  Spacehab  module,  and  placed  experiment  packages  on  Mir's  docking 
module  during  a  spacewalk. 

Mar  22  Lucid  Increment:  One  for  the  Records 

-  Aug  26  Shannon  Lucid  began  the  continuous  U.S.  presence  on  Mir  and  set  a  U.S.  single 

spaceflight  record  of  188  days.  The  Priroda  module,  with  about  2,200  pounds  of 
U.S.  science  hardware,  was  docked  to  Mir. 

Aug  STS-79:  Blaha  Succeeds  Lucid 

16  -  26  This  mission  included  a  double  Spacehab  module.  It  brought  Lucid  home  and 
replaced  her  with  John  Blaha. 

Aug  16  -  Blaha  Increment:  Keeping  it  Going 

Jan  22,  Blaha  spent  four  months  with  the  Mir-22  Cosmonaut  crew  conducting  material 
1997  science,  fluid  science,  and  life  science  research. 
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1997 


Jan 

12-22 

Jan  12 
-  May  24 


May 

15-24 


May  15 
-  Sep  25 


Sep  25 
-  Oct  6 


Sep  25  - 
Jan  31, 
1998 


STS-81:  Linenger  Succeeds  Blaha 

On  this  mission,  Jerry  Linenger  replaeed  Blaha. 

Linenger  Increment:  A  Spaeewalk  and  a  Fire 

Linenger  conducted  the  first  spacewalk  by  a  U.S.  astronaut  wearing  a  Russian 
spacesuit  and  experienced  the  onboard  fire  in  February. 

STS-84:  Foale  Succeeds  Linenger 

This  mission  carried  up  Linenger's  replacement  Mike  Foale,  along  with  Russian 
mission  specialist  Elena  V.  Kondakova. 

Foale  Increment:  Collision  and  Recovery 

Foale  experienced  the  collision  with  the  Progress,  which  damaged  the  Spektr 
module  and  caused  the  loss  of  some  science  experiments.  A  remarkable  salvage 
and  replanning  effort  by  Foale  and  the  science  community  maximized  the 
scientific  return.  Foale  conducted  a  spacewalk  with  Anatoly  Solovyev  to  survey 
damage  to  the  Spektr  module. 

STS-86:  Wolf  Succeeds  Foale 

David  Wolf  boarded  Mir  with  this  mission,  replacing  Foale.  Astronaut  Scott 
Parazynski  and  cosmonaut  VladiMir  Titov  conducted  a  joint  spacewalk,  the  first 
in  which  a  Russian  wore  a  U.S.  spacesuit. 

Wolf  Increment:  Back  Toward  Normal 

Wolf  conducted  a  spacewalk  in  January  with  cosmonaut  Solovyev  to  conduct 
scientific  experiments. 


1998 


Jan  STS-89:  Thomas  Succeeds  Wolf 

22-31  This  mission  replaced  Wolf  with  Andy  Thomas.  The  flight  also  carried  cosmonaut 
Salizhan  Sharipov  to  Mir. 

Jan  22  Thomas  Increment:  Smoothest  Sailing 

-  Jun  12  Thomas  studied  meteorology,  ocean  biochemistry,  and  human  adaptation  to 

microgravity. 

Jun  STS-91:  Closing  Out  Shuttle-Mir 

2-12  This  mission  picked  up  Thomas  and  conducted  scientific  investigations.  Phase  1 
came  to  a  close. 
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APPENDIX  5.  INTERNATIONAL  SPACE  STATION  MISSION  SUMMARIES 


Spacecraft 

Launch 

Landing/ 

Deorbit 

Mission 

Mission 

Crew** 

1998 

Zarya  FGB 

1998 
Nov.  20 

In 

progress 

lA 

Control  Module 

- 

STS-88 

1998 
Dec.  4 

1998  Dec. 
15 

2A 

Unity  (Node  1)  delivery 

Robert  D.  Cabana,  Frederick  W. 

Sturckow,  Jerry  Ross,  Nancy  J.  Currie, 
James  FI.  Newman,  Sergei  Krikalev 

1999 

STS-96 

1999 

May  27 

1999  June 

6 

2A.1 

Strela/logistics  delivery 

Kent  V.  Rominger,  Rick  D.  Flusband, 
Tamara  E.  Jernigan,  Ellen  Ochoa,  Daniel 

T.  Barry,  Julie  Payette,  Valeri  Tokarev 

2000 

STS- 101 

2000 

May  19 

2000  May 
29 

2A.2a 

Logistics  delivery 

James  D..  Flalsell,  Scott  J.  Florowits,  Mary 
Ellen  Weber,  Jeffrey  N.  Williams,  James 

S.  Voss,  Susan  Flelms,  Yuri  Usachev 

Zvezda 

2000 

July  12 

In 

progress 

IR 

Service  Module 

- 

Progress 

Ml-3 

2000 
Aug.  6 

2000  Nov. 

1 

IP 

Cargo  supply 

- 

STS-106 

2000 
Sept.  8 

2000 

Sept.  19 

2A.2b 

Logistics  delivery 

Terrence  W.  Wilcutt,  Scott  D.  Altman, 
Daniel  C.  Burbank,  Edward  Tsang  Lu, 
Richard  Mastracchio,  Yuri  Malenchenko, 
Boris  Morukov 

STS-92 

2000 

Oct.  11 

2000  Oct. 
24 

3A 

Z-1  truss,  PMA-3 
docking  port  delivery 

Brian  K.  Duffy,  Pamela  A.  Melroy,  Koichi 
Wakata,  Leroy  Chiao,  Peter  J.K.  Wisoff, 
Michael  E.  Lopez-Alegria,  William  S. 
McArthur 

Permanent  presence  of  the  crew  of  three 

Soyuz  TM- 
31 

2000. 
Oct.  31 

2001  May 

6 

2R 

1st  resident  crew 
delivery 

Bill  Shepherd,  Yuri  Gidzenko,  Sergei 
Krikalev  (up)  Talgat  Musabaev,  Yuri 
Baturin,  Dennis  Tito  (down)  ** 

Progress 

Ml-4 

2000 
Nov.  16 

2001  Feb. 

8 

2P 

Cargo  supply 

- 

Endeavour 

STS-97 

2000 
Dec.  1 

2000  Dec. 
11 

4A 

Delivery  of  the  P6 
section  with  solar  arrays 

Brendt  Jett,  Michael  J.  Bloomfield,  Joseph 
R.  Tanner,  Marc  Garneau,  Carlos  I. 

Noriega 

2001 

Atlantis 

STS-98 

2001 

Feb.  7 

2001  Feb. 
20 

5A 

Destiny  (US  lab)  delivery 

Kenneth  D.  Cockrell,  Mark  L.  Polansky, 
Robert  L.  Curbeam,  Marsha  S.  Ivins, 
Thomas  D.  Jones 

Progress  M- 
44 

2001 

Feb.  26 

2001  April 
13 

3P 

Cargo  supply 

- 

Discovery 
STS- 102 

2001 
March  8 

2001 

March  21 

5A.1 

1st  and  2nd  resident 
crew  exchange, 
Leonardo  cargo  module 
delivery  and  return 

James  Wetherbee,  James  Kelly,  Andrew 
Thomas,  Paul  Richards;  Yuri  Usachev, 
James  Voss,  Susan  Helms  (ISS-2:  up), 
Bill  Shepherd,  Yuri  Gidzenko,  Sergei 
Krikalev  (ISS-1:  down)** 

Atlantis 
STS- 100 

2001 
April  19 

2001  May 

1 

6A 

Remote  manipulator 
delivery,  Raffaello  cargo 
module  delivery  and 
return 

Kent  V.  Rominger,  Jeffrey  S.  Ashby,  Chris 
A.  Fladfield,  John  L.  Phillips,  Scott  E. 
Parazynski,  Umberto  Guidoni,  Yuri  V. 
Lonchakov 

Soyuz  TM- 
32 

2001 
April  28 

2001  Oct. 
31 

2S 

Soyuz  rescue  vehicle 
replacement 

Talgat  Musabaev,  Yuri  Baturin,  Dennis 

Tito  (up)**  (This  crew  returned  onboard 
Soyuz  TM-31) 
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Cargo  supply 


Progress  2001  2001 

Ml-6  May  21  Aug.  22 


Atlantis 
STS- 104 

2001 
July  12 

2001  July 
24 

7A 

US  airlock  delivery  and 
installation  (four  tanks  on 
two  Spacelab  pallets) 

Steven  W.  Lindsey,  Charles  0.  Flobaugh, 
Michael  L.  Gernhardt,  Janet  L.  Kavandi, 

James  F.  Reilly 

Discovery 

STS-105 

2001 

Aug. 

10 

2001 

Aug.  21 

7A.1 

2nd  and  3rd  resident  crew 
exchange;  Cargo  module 
delivery  and  return 

Scott  "Doc"  Florowitz,  Frederick  Sturckow, 
Patrick  Forrester,  Daniel  Barry;  Frank 
Culbertson,  Vladimir  Dezhurov,  Mikhail 
Tyurin  (ISS-3:  up);  Yuri  Usachev,  James 
Voss,  Susan  Helms  {ISS-2:  down) 

Progress  M- 
45 

2001 

Aug. 

21 

2001 

Nov.  22 

5P 

Cargo  supply 

- 

Progress  / 
DC-1 

2001 

Sept. 

15 

In 

progress 

3R 

Dockina  Comoartment  1 
delivery 

- 

Sovuz  TM- 
33 

2001 
Oct.  21 

2002 

May  5 

3S 

Soyuz  rescue  vehicle 
replacement 

Viktor  Afanasiev,  Konstantin  Kazeev,  Claudie 
Flaignere  (ESA)  (This  crew  returned  onboard 
Soyuz  TM-32) 

Progress 

Ml-7 

2001 

Nov. 

26 

2002 
March  20 

6P 

Cargo  supply 

- 

Endeavour 
STS- 108 

2001 
Dec.  5 

2001 

Dec.  17 

UF- 

1 

3rd  and  4th  resident  crew 
exchange;  The  Rafaello 
cargo  module  delivery  and 
return;  Starshine-2 
deployment 

Dom  Gorie,  Mark  Kelly,  Linda  Godwin,  Daniel 
Tani;  Yuri  Onufrienko,  Daniel  Bursch, 

Carl  Walz  (ISS-4:  up);  Frank  Culbertson, 
Vladimir  Dezhurov,  Mikhail  Tyurin  (ISS- 
3:  down) 

2002 

Progress 

Ml-8 

2002 

March 

21 

2002 

June  25 

7P 

Cargo  supply 

- 

Atlantis 
STS- 110 

2002 
April  8 

2002 

April  19 

8A 

SO  truss  delivery 

Michael  J.  Bloomfield,  Stephen  N.  Frick,  Rex 

J.  Walheim.  Ellen  Ochoa,  Lee  M.  E.  Morin, 
Jerry  L.  Ross,  Steven  L.  Smith 

Sovuz  TM- 
34 

2002 

April 

25 

2002 

Nov.  10 

4S 

Soyuz  rescue  vehicle 
replacement 

Yuri  Gidzenko,  Roberto  Vittori,  Mark 
Shuttleworth.  (This  crew  returned  onboard 
Soyuz  TM-33) 

Endeavour 

STS-111 

2002 
June  5 

2002 

June  19 

UF- 

2 

4th  and  5th  resident  crew 
exchange;  Leonardo 
Multipurpose  Logistics 
Module,  Mobile  Base  System 
delivery 

Ken  Cockrell,  Paul  Lockhart,  Franklin  Chang- 
Diaz,  Philippe  Perrin;  Yuri  Onufrienko, 
Daniel  Bursch,  Carl  Walz  (ISS-4:  down); 
Valery  Korzun,  Peggy  Whitson,  Sergei 
Treshev  (ISS-5:  up) 

Progress  M- 
46 

2002 

June 

26 

2002 

Oct.  14 

8P 

Cargo  supply 

- 

Progress 

Ml-9 

2002 

Sept. 

25 

2003 

Feb.  1 

9P 

Cargo  supply 

- 

Atlantis 
STS- 112 

2002 
Oct.  7 

2002 

Oct.  18 

9A 

SI  truss  delivery 

Jeffrey  S.  Ashby,  Pamela  A.  Melroy,  David  A. 
Wolf,  Piers  J.  Sellers,  Sandra  FI.  Magnus, 
Fyodor  N.  Yurchikhin. 

Sovuz  TMA- 
1 

2002 
Oct.  30 

2003 

May  4 

5S 

Soyuz  rescue  vehicle 
replacement;  ISS-6  return 

Sergei  Zalyotin,  Yuri  Lonchakov,  Frank  De 
Winne  (Beigium/ESA:  up).  (This  crew 
returned  onboard  Soyuz  TM-34)  Ken 

Bowersox,  Don  Petit,  Nikolai  Budarin 

(ISS-6:  down) 

Endeavour 
STS- 113 

2002 

Nov. 

23 

2002 

Dec.  7 

llA 

PI  truss,  Expedition  6  and  5 
exchange 

Jim  Wetherbee,  Paul  Lockhart,  Michael 
Lopez-Alegria,  John  Flerrington,  Ken 

Bowersox,  Don  Petit,  Nikolai 

Budarin. (ISS-6:  up);  Valery  Korzun, 

100 


Cargo  supply 


Progress  2001  2001 

Ml-6  May  21  Aug.  22 


Atlantis 
STS- 104 

2001 
July  12 

2001  July 
24 

7A 

US  airlock  delivery  and 
installation  (four  tanks  on 
two  Spacelab  pallets) 

Steven  W.  Lindsey,  Charles  0.  Flobaugh, 
Michael  L.  Gernhardt,  Janet  L.  Kavandi, 

James  F.  Reilly 

Discovery 

STS-105 

2001 

Aug. 

10 

2001 

Aug.  21 

7A.1 

2nd  and  3rd  resident  crew 
exchange;  Cargo  module 
delivery  and  return 

Scott  "Doc"  Florowitz,  Frederick  Sturckow, 
Patrick  Forrester,  Daniel  Barry;  Frank 
Culbertson,  Vladimir  Dezhurov,  Mikhail 
Tyurin  (ISS-3:  up);  Yuri  Usachev,  James 
Voss,  Susan  Helms  (ISS-2:  down) 

Progress  M- 
45 

2001 

Aug. 

21 

2001 

Nov.  22 

5P 

Cargo  supply 

- 

Progress  / 
DC-1 

2001 

Sept. 

15 

In 

progress 

3R 

Dockina  Comoartment  1 
delivery 

- 

Soyuz  TM- 
33 

2001 
Oct.  21 

2002 

May  5 

3S 

Soyuz  rescue  vehicle 
replacement 

Viktor  Afanasiev,  Konstantin  Kazeev,  Claudie 
Flaignere  (ESA)  (This  crew  returned  onboard 
Soyuz  TM-32) 

Progress 

Ml-7 

2001 

Nov. 

26 

2002 
March  20 

6P 

Cargo  supply 

- 

Endeavour 
STS- 108 

2001 
Dec.  5 

2001 

Dec.  17 

UF- 

1 

3rd  and  4th  resident  crew 
exchange;  The  Rafaello 
cargo  module  delivery  and 
return;  Starshine-2 
deployment 

Dom  Gorie,  Mark  Kelly,  Linda  Godwin,  Daniel 
Tani;  Yuri  Onufrienko,  Daniel  Bursch, 

Carl  Walz  (ISS-4:  up);  Frank  Culbertson, 
Vladimir  Dezhurov,  Mikhail  Tyurin  (ISS- 
3:  down) 

2002 

Progress 

Ml-8 

2002 

March 

21 

2002 

June  25 

7P 

Cargo  supply 

- 

Atlantis 
STS- 110 

2002 
April  8 

2002 

April  19 

8A 

SO  truss  delivery 

Michael  J.  Bloomfield,  Stephen  N.  Frick,  Rex 

J.  Walheim.  Ellen  Ochoa,  Lee  M.  E.  Morin, 
Jerry  L.  Ross,  Steven  L.  Smith 

Sovuz  TM- 

M 

2002 

April 

25 

2002 

Nov.  10 

4S 

Soyuz  rescue  vehicle 
replacement 

Yuri  Gidzenko,  Roberto  Vittori,  Mark 
Shuttleworth.  (This  crew  returned  onboard 
Soyuz  TM-33) 

Endeavour 

STS-111 

2002 
June  5 

2002 

June  19 

UF- 

2 

4th  and  5th  resident  crew 
exchange;  Leonardo 
Multipurpose  Logistics 
Module,  Mobile  Base  System 
delivery 

Ken  Cockrell,  Paul  Lockhart,  Franklin  Chang- 
Diaz,  Philippe  Perrin;  Yuri  Onufrienko, 
Daniel  Bursch,  Carl  Walz  (ISS-4:  down); 
Valery  Korzun,  Peggy  Whitson,  Sergei 
Treshev  (ISS-5:  up) 

Progress  M- 
46 

2002 

June 

26 

2002 

Oct.  14 

8P 

Cargo  supply 

- 

Progress 

Ml-9 

2002 

Sept. 

25 

2003 

Feb.  1 

9P 

Cargo  supply 

- 

Atlantis 
STS- 112 

2002 
Oct.  7 

2002 

Oct.  18 

9A 

SI  truss  delivery 

Jeffrey  S.  Ashby,  Pamela  A.  Melroy,  David  A. 
Wolf,  Piers  J.  Sellers,  Sandra  FI.  Magnus, 
Fyodor  N.  Yurchikhin. 

Sovuz  TMA- 
1 

2002 
Oct.  30 

2003 

May  4 

5S 

Soyuz  rescue  vehicle 
replacement;  ISS-6  return 

Sergei  Zalyotin,  Yuri  Lonchakov,  Frank  De 
Winne  (Beigium/ESA:  up).  (This  crew 
returned  onboard  Soyuz  TM-34)  Ken 

Bowersox,  Don  Petit,  Nikolai  Budarin 

(ISS-6:  down) 

Endeavour 

2002 

Nov. 

23 

2002 

llA 

PI  truss,  Expedition  6  and  5 

Jim  Wetherbee,  Paul  Lockhart,  Michael 
Lopez-Alegria,  John  Flerrington,  Ken 

Bowersox,  Don  Petit,  Nikolai 

STS- 113 

Dec.  7 

exchange 

Budarin. (ISS-6:  up);  Valery  Korzun, 

Peggy  Whitson,  Sergei  Treshev  (ISS-5: 

down) 
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1  Columbia  accident  grounds  the  Shuttle  fleet,  forces  the  reduction  of  the  ISS  crew  to  two  I 

Progress  M-  2003 

47  Feb.  2 

2003 
Aug.  28 

lOP 

Cargo  supply 

- 

_  T-.,.  2003 

Sovuz  TMA-2  . 

— ^ -  April  26 

2003 
Oct.  28 

6S 

Soyuz  rescue  vehicle 
replacement;  ISS-7  crew 
delivery 

Yuri  Malenchenko,  Ed  Lu  (ISS-7) 

Progress  Ml-  2003 

10  No.  259  June  8 

2003 
Oct.  3 

IIP 

Cargo  supply 

- 

Progress  M-  2003 

48  Aug.  29 

2004 
Jan.  28 

12P 

Cargo  supply 

- 

_  ■,  2003 

Oct.  18 

2004 
April  30 

7S 

Soyuz  rescue  vehicle 
replacement;  ISS-8  crew 
delivery 

Alexander  Kaleri,  Michael  Foale  (ISS-8), 
Pedro  Duque  (ESA/Spain)  (Duque  returned 
onboard  Soyuz  TMA-2) 

2004 

Progress  Ml-  2004 

11  No.  260  Jan.  29 

2004 
June  3 

13P 

Cargo  supply 

- 

_  .  2004 

Sovuz  TMA-4  . 

— ^ -  April  19 

2004 
Oct.  24 

8S 

Soyuz  rescue  vehicle 
replacement;  ISS-9  crew 
delivery 

Gennady  Padalka,  Michael  Fincke  (ISS-9), 
Andre  Kuipers  (ESA)  (Kuipers  returned 
onboard  Soyuz  TMA-3) 

Progress  M-  2004 

49  No.  249  May  25 

2004 
July  30 

14P 

Cargo  supply 

- 

Progress  M-  2004 

50  No.  350  Aug.  11 

2004 
Dec.  23 

15P 

Cargo  supply 

- 

S°y^^TMA-5 

2005 
April  24 

9S 

Soyuz  rescue  vehicle 
replacement;  ISS- 10  crew 
delivery 

Leroy  Chiao,  Salizhan  Sharipov  (ISS-10), 
Yuri  Shargin  (Shargin  returned  onboard  Soyuz 
TMA-4) 

Progress  M-  2004 

51  No.  351  Dec.  24 

2005 
March  9 

16P 

Cargo  supply 

- 

2005 

Progress  M-  2005 

52  No.  352  Feb.  28 

2005 
June  16 

17P 

Cargo  supply 

- 

„  -p.. .  p  2005 

Sovuz  TMA-6  . 

— ^ -  April  15 

2005 
Oct.  11 

lOS 

Soyuz  rescue  vehicle 
replacement;  ISS- 11  crew 
delivery 

Sergei  Krikalev,  John  Phillips  (ISS-11), 
Roberto  Vittori  (Italy)  (Vittori  returned 
onboard  Soyuz  TMA-5)  (Gregory  Olsen:  down 
only) 

Progress  M-  2005 

53  No.  353  June  17 

2005 
Sept.  7 

18P 

Cargo  supply 

- 

Discovery  2005 
STS-114  July  26 

2005 
Aug.  9 

LFl 

Raffaello  Multi-Purpose 
Logistics  Module  delivery 
and  return,  cargo  supply 

Eileen  Collins,  James  Kelly,  Charles  Camarda, 
Wendy  Lawrence,  Soichi  Noguchi  (Japan), 

Steve  Robinson,  Andy  Thomas 

Progress  M-  2005 

54  No.  354  Sept.  8 

2006 
March  3 

19P 

Cargo  supply 

- 

„  -7  2005 

Oct.  1 

2006 
April  9 

IIS 

Soyuz  rescue  vehicle 
replacement;  ISS- 12  crew 
delivery 

William  McArthur,  Valery  Tokarev,  Gregory 
Olsen  (up  only)  (Gregory  Olsen  returned 
onboard  Soyuz  TMA-6)  Marcos  Pontes  (Brazil) 
down  only 

Progress  M-  2005 

55  No.  355  Dec.  24 

2006 
June  19 

20P 

Cargo  supply 

- 

2006 

2006 

Soyuz  TMA-8  March 

30 

2006 

Sept. 

29 

12S 

Soyuz  rescue  vehicle 
replacement;  ISS- 13  crew 
delivery 

Pavel  Vinogradov,  Jeffrey  Williams, 

Marcos  Pontes  (Brazil)  (up  only)  (Pontes 
returned  onboard  Soyuz  TMA-7);  Anousheh 
Ansari  (down  only) 
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n  2006 

Progress  M- 
56  No.  356  24 

2006 

Sept. 

19 

21P 

Cargo  supply 

- 

n  2006 

Progress  M-  , 

June 

57  No.  357  24 

2007 
Jan.  17 

22P 

Cargo  supply 

- 

Discovery  2006 
STS-121  July  4 

2006 
July  17 

ULFl.l 

Multi-Purpose  Logistics 
Module  (MPLM); 
Integrated  Cargo  Carrier 
(ICC); 

Lightweight  Multi-Purpose 
Experiment  Support 
Structure  Carrier  (LMC); 
ESA  astronaut  delivery 

Steven  Lindsey,  Mark  Kelly,  Lisa  Nowak, 

Michael  Possum,  Stephanie  Wilson,  Piers 

Sellers,  Thomas  Reiter  (up  only)(ESA). 

V  2006 

Atlantis  _  ^ 

STS-115 

2006 

Sept. 

21 

12A 

Second  port  truss 
segment  (ITS  P3/P4) 
Second  set  of  solar  arrays 
and  batteries 

Brent  W.  Jett  Jr.,  Christopher  J.  Ferguson, 
Heidemarie  M.  Stefanyshyn-Piper,  Joseph  R. 
Tanner,  Daniel  C.  Burbank  and  Steven  G. 
MacLean,  CSA. 

_  -p...  2006 

Sovuz  TMA-  ^  . 

^ -  Sept. 

-  18 

2007 

April 

21 

13S 

Soyuz  rescue  vehicle 
replacement;  ISS-14  crew 
delivery 

Michael  E.  Lopez-Alegria,  Mikhail  Tyurin, 

Anousheh  Ansari  (up  only)  (returned  onboard 
Soyuz  TMA-8)  Charles  Simony!  (down  only) 

n  2006 

Progress  M- 
58  No.  358  2- 

2007 

March 

28 

23P 

Cargo  supply 

- 

Discovery  2006 

STS-116  Dec.  9 

2006 

Dec. 

22 

12A.1 

Third  port  truss  segment 
(ITS  P5)  delivery; 
SPACEHAB  single  cargo 
module  and  Integrated 
Cargo  Carrier  (ICC) 
remain  in  the  cargo  bay 

Mark  Polansky,  William  Oefelein,  Robert 
Curbeam,  Joan  Higginbotham,  Nicholas 

Patrick,  Christer  Fuglesang  (ESA);  Sunita 
Williams  (up  only;  returns  onboard  STS-117); 
Thomas  Reiter  (ESA)  (down  only); 

2007 

n  2007 

Progress  M-  . 

59  No.  359 

lo 

2007 
Aug.  1 

24P 

Cargo  supply 

- 

Sovuz  TMA-  2007 
10  April  7 

2007 
Oct.  21 

14S 

Expedition  15  delivery 

Fyodor  Yurchikhin,  Oleg  Kotov,  Charles 
Simonyi  (up  only;  returned  onboard  Soyuz 
TMA-9);  Muszaphar  Shukor  (Malaysia);  (down 
only,  launched  onboard  Soyuz  TMA-11) 

n  2007 

Progress  M- 

60  No.  360 

2007 

Sept. 

25 

25P 

Cargo  supply 

- 

Atlantis  2007 

STS-117  Junes 

2007 

June 

22 

13A 

Second  starboard  truss 
segment  (ITS  S3/S4)  with 
Photovoltaic  Radiator 
(PVR) 

Third  set  of  solar  arrays 
and  batteries 

Frederick  W.  Sturckow,  Lee  Joseph 

Archambault,  James  F.  Reilly  II,  Steven  R. 
Swanson,  Patrick  G.  Forrester,  John  D.  Olivas, 

Clayton  C.  Anderson  (up  only),  Sunita  L. 
Williams  (down  only) 

Progress  M-  2007 
61  No.  361  Aug.  2 

2008 
Jan.  22 

26P 

Cargo  supply 

- 

Endeavour  2007 
STS-118  Aug.  8 

2007 

Aug. 

21 

13A.1 

SPACEHAB  Single  Cargo 
Module 

Third  starboard  truss 
segment  (ITS  S5) 
External  Stowage  Platform 
3  (ESP3) 

Scott  Kelly,  Charlie  Hobaugh,  Tracy  Caldwell, 
Rick  Mastracchio,  Dave  Williams,  Barbara 
Morgan,  Al  Drew 

^  2007 

Soyuz  TMA- 

11 

—  10 

2008 

April 

19 

15S 

Expedition  16  delivery 

Peggy  A.  Whitson,  Yuri  Malenchenko, 

Sheikh  Muszaphar  Shukor  (Malaysia)  (up  only; 
returns  onboard  Soyuz  TMA-10);  So-yeon  Yi, 
(South  Korea)  (down  only;  launched  onboard 
Soyuz  TMA-12) 
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Pamela  A.  Melroy,  George  D. 


Discovery 

STS-120 

2007  Oct. 

23 

2007  Nov. 

7 

lOA 

Node  2  (Flarmony)  Zamka;  Douglas  FI.  Wheelock,  Scott 
E.  Parazynski,  Stephanie  D.  Wilson, 
Sidewall  -  Power  Paolo  Nespoli  (ESA);  Daniel  M. 
and  Data  Grapple  Tani;  (up  only)  Clayton  C. 

Fixture  (PDGF)  Anderson  (down  only) 

Progress 
M-62  No. 
362 

2007  Dec. 

23 

2008  Feb. 

15 

27P 

Cargo  supply 

2008 

Progress 

M-63 

2008  Feb. 

5 

2008  April 
7 

28P 

Cargo  supply 

- 

Columbus 

European 

Laboratory  Module 

Atlantis 

STS-122 

2008  Feb. 

7 

2008  Feb. 
20 

IE 

Multi-Purpose 
Experiment 
Support  Structure 
Non-Deployable 
(MPESS-ND) 

Stephen  Frick,  Alan  Poindexter, 
Leland  Melvin,  Rex  Walheim, 

Stanley  Love,  Leopold  Eyharts 
(ESA)  (up  only).  Flans  Schlegel 
(ESA) 

ATV-1 

2008  March  2008 

9  Sept.  29 

ATVl 

Cargo  supply 

- 

Kibo  Japanese 
Experiment 
Logistics  Module  - 
Pressurized 
Section  (ELM-PS) 

Spacelab  Pallet  -  Dominic  Gorie,  Gregory  H.  Johnson, 
Deployable  1  (SLP- Robert  L.  Behnken,  Mike  Foreman, 
Dl)  with  Canadian  Rick  Linnehan,  Garrett  Reisman, 
Special  Purpose  (up  only;  returns  with  STS-124) 
Dexterous  Takao  Doi  (JAXA);  Leopold 

Endeavou  2008  March  2008  Manipulator,  Eyharts  (ESA)  (down  only;  arrived 

rSTS-123  11  March  26  IJ/A  Dextre  with  STS-122) 


Sovuz  2008  April  2008  Oct.  Expedition  17 

TMA-12  8  24  16S  delivery 


Sergei  Volkov,  Oleg  Kononenko,  So- 
veon  Yi,  (South  KoreaJ  (up  only; 
returns  onboard  Sovuz  TMA-ll); 
Richard  Garriott  (down  only;  arrived 
onboard  Sovuz  TMA-13J 
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Progress 

2008  May 

2008 

M-64 

15 

Sept.  9 

29P 

Cargo  supply 

- 

Kibo  Japanese 
Experiment 
Module 
Pressurized 
Moduie  (JEM-PM) 

Mark  Keiiy,  Ken  Ham,  Karen 
Nyberg,  Ron  Garan,  Mike  Possum, 


Discovery 
STS- 124 

2008  May 
31 

2008  June 

14 

ij 

Japanese  Remote  Akihiko  Hoshide,  Greg  Chamitoff 
Manipulator  (up  only);  Garrett  Reisman  (down 

System  (JEM  RMS)  only;  arrived  with  STS-123) 

Progress 

M-65 

2008  Sept. 
10 

2008  Dec. 

7 

30P 

Cargo  supply 

- 

Sovuz 

TMA-13 

2008  Oct. 

12 

In 

progress 

17S 

Expedition  18 
delivery 

E.  Michael  Fincke,  Yurv  Lonchakov, 
Richard  Garriott,  (USA)  (uo  onlv; 
returns  onboard  Sovuz  TMA-12) 

Endeavou 
r  STS-126 

2008  Nov. 

14 

2008  Nov. 
30 

ULF2 

Leonardo  Multi- 
Purpose  Logistics 
Module  (MPLM) 

Christopher  J.  Ferguson,  Eric  A. 

Boe,  Stephen  G.  Bowen,  Donald  R. 
Pettit,  Robert  S.  (Shane)  Kimbrough 
and  Heidemarie  M.  Stefanyshyn- 
Piper;  Sandra  H.  Magnus,  (up 
only,  returns  with  STS-119),  Greg 
Chamitoff  (down  only;  arrived  with 
STS-124) 

Prooress 

M-OIM 

2008  Nov. 
26 

2009  Feb. 

8 

31P 

Cargo  supply 

- 

2009 

Progress 

2009  Feb. 

In 

M-66 

10 

progress 

32P 

Cargo  supply 

- 

105 


